From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 15 Nov 93 16:16:09 EST Subject: Linux-Development Digest #228 Linux-Development Digest #228, Volume #1 Mon, 15 Nov 93 16:16:09 EST Contents: Re: Moving an X-Window from one computer to another. (Timothy J. Bogart) Re: 4.3 BSD sendmsg/recvmsg (Doug McIntyre) Re: 16550A handling in serial.c (Matthew Dillon) Re: Motif - Pay? BAH! (Drinks All The Water) Re: [Q] mmap implementation / persistency (Lawrence Foard) Trantor T130B SCSI Driver (Keith A. Hollen) WANT Slackware for 5.25 disks (a cute boy!!) Re: 16550A handling in serial.c (Harald Koenig) compressed fs ??? (Norbert Kuemin) Re: Motif Project (Peter Orbaek) Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? (Ty Sarna) Re: Moving an X-Window from one computer to another. (Brandon S. Allbery) Re: Motif - Pay? BAH! (peter j dohm) Re: compressed fs ??? (Alain Knaff) Re: compressed fs ??? (Cedric Adjih) ---------------------------------------------------------------------------- From: tjb@NeoSoft.com (Timothy J. Bogart) Subject: Re: Moving an X-Window from one computer to another. Date: Sun, 14 Nov 1993 23:02:57 GMT In article <2c6ait$55@amhux3.amherst.edu> jedubins@unix.amherst.edu (Just a fellow traveller...) writes: >Of course this problem is much more difficult to handle with X-windows because >of many of the environmental concerns that Brandon brought up, but I can think >of at least one environment that does this pretty well: Macs. In some >ways it's like comparing apples and oranges, because you can't move a >a window from _one machine to another_- but individual machines can have >multiple displays you can move windows, and the mouse pointer across. It's one >of the capabilities I've always liked in the make environment. It would be >neat if the X environment had software extensions to allow us to do something >like this. I wonder if the X consortium would consider adding this to the >next release after X11R6. > > Jim I saw this done with x11r4 and was told it was pretty much a compile switch. Multiple monitors, that is. Scroll your cursor back and forth between monitors, etc. Isn't this what the display:0.x is for? ------------------------------ From: merlyn@jacobs.jacobs.mn.org (Doug McIntyre) Subject: Re: 4.3 BSD sendmsg/recvmsg Date: 14 Nov 1993 11:28:01 -0600 M.C.Little@newcastle.ac.uk (Mark Little) writes: >The latest version of Linux which we have (0.99.13q) supports send/sendto >and recv/recvfrom. Are there any plans to support the other 4.3 BSD >primitives for sending and receiving scatter/gather buffers, i.e., sendmsg >and recvmsg? We have some software which uses these. I'd be interested in some work arounds for these system calls if anybody has done something like that. (Or for them to be implemented in the kernel with lib stubs would be really great :). I need them as well.. -- merlyn@jacobs.mn.org I don't wanna watch TV... I don't wanna listen to the Corporations.. I don't wanna drown in American Society.. -- L7 ------------------------------ From: dillon@moonshot.west.oic.com (Matthew Dillon) Subject: Re: 16550A handling in serial.c Date: 14 Nov 1993 18:53:18 -0800 In article koenig@ceres.tat.physik.uni-tuebingen.de (Harald Koenig) writes: >In <2brcop$g2f@moonshot.west.oic.com> dillon@moonshot.west.oic.com (Matthew Dillon) writes: >... >> feature is a thousand times more important then a 32x sampling rate, >> and all UARTs have it. > >> -Matt > >My interesst is not in performance or reliability. > >... >signal (which is detected as start bit). with the current UARTs I only get >a resolution of 1.25 ms which isn't god enough. > >Harald > >-- >Harald Koenig, Inst.f.Theoret.Astrophysik (koenig@tat.physik.uni-tuebingen.de) > > All SCSI disks will from now on be required to send an email > notice 24 hours prior to complete hardware failure! Hmm.. interesting idea, but unless you use the NMI you will not get much better then 500uS or so, and the worst case response time is probably greater then a 1 mS anyway due to the way the interrupt subsystem works and the massive amount of disabling of interrupts that occurs in the kernel. You would need medium term averaging to get any accuracy out of it, which is basically what the network time daemon stuff does for time synchronization over a network. If you need very high accuracy you will have to make a project out of it... use a microcontroller to handle the time synchronization and make the whole thing a card you can pop into a slot or something like that. -Matt Matthew Dillon dillon@moonshot.west.oic.com 1005 Apollo Way dillon@overload.berkeley.ca.us Incline Village, NV. 89451 ham: KC6LVW (no mail drop) USA Sandel-Avery Engineering (702)831-8000 [always include a portion of the original email in any response!] ------------------------------ From: boutell@netcom.com (Drinks All The Water) Subject: Re: Motif - Pay? BAH! Date: Mon, 15 Nov 1993 04:35:39 GMT In article <753286129snz@thoday.demon.co.uk> chris@thoday.demon.co.uk writes: >This thread started with a desire to be able to use software written >for Motif without having access to the Motif libraries. I would like >to suggest an alternative project: how about producing a widget set >that would allow developers to produce applications consistent with >the look-and-feel of Motif so that such applications could co-exist with >commercial applications? Do we really need software that requires 75 >pages of reference documentation to describe a simple operation? I will be making a first beta release of a package that does exactly this (*not* a drop in replacement, but Motif look and feel, and yes, free) soon. Experience has taught me never to define "soon." My "TODO" list is now considerably shorter than my "DONEDID" list, however. -T -- i'll be under the floorboards with my face in the sun ------------------------------ From: entropy@world.std.com (Lawrence Foard) Subject: Re: [Q] mmap implementation / persistency Date: Mon, 15 Nov 1993 06:17:34 GMT In article <1993Nov14.121834.7755@imec.be>, Steven Buytaert wrote: > > ----- I wrote Sheetal ----------------------------------------- > |"No mprotect is not implemented in the kernel, [...] > |On the other hand, what interests me more is > |the mmap implementation." (From the context you will notice that > |I also asked if the mmap on Linux is OK as it is now...) > --------------------------------------------------------------- > > ----- He answered ------------------------------------------------- > |"Actually, I am not sure if the mmap implementation (on Linux) > |is "broken" or "incomplete" or "as intended". As I understand it, > |mmap on Linux can map only character files into memory. This is > |exactly similar to the mmap on Ultrix. I was talking to someone > |here the other day, and I was told that the reason mmap is > |implemented in such a way is because Linux (and Ultrix) are based > |on BSD, which restricts mmap to map only character devices. > |If this is so, then I don't think there is a question of > |"fixing" mmap, since the current behaviour is probably what was > |intended. Of course, I would be happy to be proven wrong on > |this matter." > ------------------------------------------------------------------- This was true uptill a month or so again, it now handles all files (but read only last time I checked). I use the feature all the time for handling large images with an incredible improvment in performance. -- ====== Legalize: >==--< | have given us jacks. . . \ / You are ~1,000,000,000,000,000 .1ms NAND gates have a nice day. . . . \/ The true theory of everything will run on a finite turing machine. . . . ------------------------------ Subject: Trantor T130B SCSI Driver From: kah@hollen.atl.ga.us (Keith A. Hollen) Date: Sun, 14 Nov 1993 15:48:45 GMT Is anyone working on a driver for the Trantor T130B SCSI card? I'm using it for my NEC CDR-84 and Linux doesn't recognize it. I'd like to get it working since I paid $89 for it and don't want to have to buy another SCSI card at this time. The card works with MS-DOS and OS2 2.x. By the way, I'm running a 0.99.12 kernel. Thanks in advance for your help! -- Keith A. Hollen | "Don't blame me ... kah@hollen.atl.ga.us | ... I voted for Bill and Opus!" -- Keith A. Hollen | "Don't blame me ... kah@hollen.atl.ga.us | ... I voted for Bill and Opus!" ------------------------------ From: pschen@Winkie.Oz.nthu.edu.tw (a cute boy!!) Subject: WANT Slackware for 5.25 disks Date: 15 Nov 1993 08:57:45 GMT Hello: Is there Slackware version for 5.25 disks? I very need it. thanks !! pschen 1993.11.15 ------------------------------ From: koenig@ceres.tat.physik.uni-tuebingen.de (Harald Koenig) Subject: Re: 16550A handling in serial.c Date: 15 Nov 93 10:17:35 GMT In <2c6quu$7qc@moonshot.west.oic.com> dillon@moonshot.west.oic.com (Matthew Dillon) writes: > Hmm.. interesting idea, but unless you use the NMI you will not get much > better then 500uS or so, and the worst case response time is probably > greater then a 1 mS anyway due to the way the interrupt subsystem works > and the massive amount of disabling of interrupts that occurs in the Well, it's not that bad in Linux using standard interrupts: on my 486/dx2-66 I played a bit with the timer interrupt for the scheduler which runns at 100 Hz. The interrupt is generated from a 8254 timer which runns at 1.19MHz. so reading the timer i get usec accurancy which is quite nice for doing such timing analysis. When I read the timer latch in the interrupt (to see how long it was running after the interrupt was signaled when counting throug zero) and plot a histogram from the interrupt latency (using gnuplot and with log y), very very few interrupt don't lie in the 11-12 usec interval from a sample over several hours when I did kernel compilation and heady disk i/o and swaping for quite some time. Of course Linux is no real time os at all (not yet?!) but for what i'm doing 99.9% would be enough (and that seems to be possible with Linux). but i've to admit that from time to time (about one time every few days), Linux still looses clock interrupts (always 2 interrupts at once, so the is at least one place in kernel where interrupts were locked for more than 10 ms). > If you need very high accuracy you will have to make a project out of > it... use a microcontroller to handle the time synchronization and > make the whole thing a card you can pop into a slot or something like > that. at the moment, it's only my private interest to see, what's possible with Linux and Intel and to play with clock synchronisation stuff in this deep, but I know applications which tend to have the same requirements. Harald -- Harald Koenig, Inst.f.Theoret.Astrophysik (koenig@tat.physik.uni-tuebingen.de) All SCSI disks will from now on be required to send an email notice 24 hours prior to complete hardware failure! ------------------------------ From: kuemin@srapc101.alcatel.ch (Norbert Kuemin) Subject: compressed fs ??? Reply-To: norbert.kuemin@alcatel.ch Date: Mon, 15 Nov 1993 10:26:30 GMT Hi all, does anyone know if there is an fs (filesystem) witch compress automaticly (like stacker in MSDOS) ? =======================================+======================================= +----------V----------+ Eltech. ING HTL|EMAIL: norbert.kuemin@alcatel.ch | A L C A T E L | Norbert Kuemin |DEC: PSI%(0228)4795123920::ZAD_KUEMIN +---------------------+ Alcatel STR |X.400: c=CH a=arCom p=Alcatel S T R CH-8804 Au/ZH | s=Kuemin g=Norbert =======================================+======================================= ------------------------------ From: poe@daimi.aau.dk (Peter Orbaek) Subject: Re: Motif Project Date: 15 Nov 1993 10:40:18 GMT Thus spake olaf@toppoint.de (Olaf Schlueter): >Part of the FWF widgets are written in a web-like language which >looks promising. The precompiler (wbuild) dumps core on my machine >yet. If someone has already ported it successfully using it >would surely boost up development speed. I have made wbuild 2.0 run on Linux. There were some memory allocation bugs related to the use of keyboard accelerators, but I think I fixed them. I also mailed the author about the bugs, and he promised the would be fixed in the next release. I can bunch my patched version together and mail it if you want, just have to go home and get it, I don't have my linux box online. - Peter. >-- >Olaf Schlüter, Sandkuhle 4-6, 24103 Kiel, Germany, Toppoint Mailbox e.V. >"MSDOS didn't get as bad as it is overnight -- it took over ten years >of careful development." David Megginson -- Peter Orbaek Phone: +45 89 42 32 23 Comp. Sci. Department of Aarhus University, Denmark. ------------------------------ From: tsarna@endicor.com (Ty Sarna) Crossposted-To: comp.os.386bsd.development,comp.os.386bsd.misc Subject: Re: Has anyone written a Mac FS or Mac FS Access utilities for Linux or 386BSD? Date: 15 Nov 93 02:41:40 GMT In article c9107786@peach.newcastle.edu.au (David Leonard) writes: > lih@news.cs.columbia.edu (Andrew "Fuz" Lih) writes: > > CAP does that. Its quite a natural thing to do in a UFS, to put things in > directories. The macintosh file "foo" would appear as: > > ./foo (the data fork) > ./.resource/foo (the resource fork) > ./.finderinfo/foo (other stuff) Why not handle it the way isofs does (I believe it makes the resource fork appear as a file of the same name, but with '=' prepended). It would be nice to have some consistency in these things. > I dont think you should nasty up the kernel to handle non-flat (bent?) files, > just like I dont think you should nasty it up for non-flat memory addr spaces. I have to agree. Forked files are bad news, IMHO. -- Ty Sarna "Don Johnson is back -- back in time, and battling drug-trafficking dinosaurs. Don Johnson -is- tsarna@endicor.com Jurassic Narc. Tuesdays at 8; 7 Central & Mountain" ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Moving an X-Window from one computer to another. Date: Mon, 15 Nov 1993 12:50:02 GMT In article tjb@NeoSoft.com (Timothy J. Bogart) writes: >In article <2c6ait$55@amhux3.amherst.edu> jedubins@unix.amherst.edu (Just a fellow traveller...) writes: >>Of course this problem is much more difficult to handle with X-windows because >>of many of the environmental concerns that Brandon brought up, but I can think >>of at least one environment that does this pretty well: Macs. In some >>ways it's like comparing apples and oranges, because you can't move a >>a window from _one machine to another_- but individual machines can have >>multiple displays you can move windows, and the mouse pointer across. It's one > >I saw this done with x11r4 and was told it was pretty much a compile >switch. Multiple monitors, that is. Scroll your cursor back and >forth between monitors, etc. Isn't this what the display:0.x is for? Moving the mouse pointer is one thing. Moving windows is quite another. I would suspect that the Mac can handle it more easily because its window scheme uses a 1-bit display as the lowest common demoninator, whereas X allows windows to be created in visuals which in effect define the lowest common denominator for the window in question --- so a window in an 8-plane visual can't easily be moved to a 1-plane screen. ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: dohm@cis.ohio-state.edu (peter j dohm) Subject: Re: Motif - Pay? BAH! Date: 15 Nov 1993 10:00:19 -0500 >I think that's what I said. What has fvwm/twm/gwm/whatever-the-fave-rave-is >have to do with being able to build Mosaic? Nothing. > >So why are people saying the "right" window manager for Mosaic is >fvwm? this argument is really quite mute. I simply said in the beginning that I'd much rather take fvwm and extend with my motif library rather than re-writing mwm. This is why i'd originally said "fvwm is the w.m. of choice" it's got nothing at all to do with mosaic.. please let the dead dog rot. Pete --- +---------------------------------------------------------------------------+ | Peter J. Dohm - Comp. Science Major | The Ohio State University | | ** dohm@magnus.acs.ohio-state.edu ** | ak541@cleveland.freenet.edu | | dohm.1@osu.edu, dohm@cis.ohio-state.edu | dohm@cis.ohio-state.edu | +---------------------------------------------------------------------------+ ------------------------------ From: knaff@imag.fr (Alain Knaff) Subject: Re: compressed fs ??? Date: 15 Nov 1993 15:22:34 GMT norbert.kuemin@alcatel.ch writes: >Hi all, > >does anyone know if there is an fs (filesystem) witch compress automaticly >(like stacker in MSDOS) ? Last Friday, I uploaded a library patch to sunsite.unc.edu which allows programs to uncompress datafiles on the fly. (Thus allowing you to store these datafiles compressed.) It is on sunsite.unc.edu:/pub/Linux/libs/zlibc.src.tar.gz . There is also a binary distribution in sunsite.unc.edu:/pub/Linux/libs/zlibc.so.4.4.4.tar.gz The documentation is only included in the source distribution, not in the binary distribution. Hope this helps, Alain Knaff ------------------------------ From: adjihc4@cti.ecp.fr (Cedric Adjih) Subject: Re: compressed fs ??? Date: 15 Nov 1993 16:46:16 GMT Alain Knaff (knaff@imag.fr) wrote: : norbert.kuemin@alcatel.ch writes: : >Hi all, : > : >does anyone know if there is an fs (filesystem) witch compress automaticly : >(like stacker in MSDOS) ? : Last Friday, I uploaded a library patch to sunsite.unc.edu which allows : programs to uncompress datafiles on the fly. (Thus allowing you to store : these datafiles compressed.) : It is on sunsite.unc.edu:/pub/Linux/libs/zlibc.src.tar.gz . Well, this sound great, since there is also tcx in utils/compress/tcx.1.1.tar.z, which allows you to uncompress executables on the fly (Thus allowing you to store these executables compressed). [ btw : tcx compress and decompress executables using gzip (transparently). Do not do like me, do not try to compress gzip :-)] : Hope this helps, : Alain Knaff This is not yet a compressed file system, but I hope this can help..., -- Cedric Adjih / Internet : adjihc4@cti.ecp.fr Disclamer : concerning my English. "Nuclear War can ruin your whole compile." -- Karl Lehenbauer ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************