From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Mon, 25 Oct 93 01:14:07 EDT Subject: Linux-Development Digest #187 Linux-Development Digest #187, Volume #1 Mon, 25 Oct 93 01:14:07 EDT Contents: Linux Astronomy update? (Ron Watkins) Re: /dev not needed? (Brandon S. Allbery) [Q] NTFS for Linux, Anyone ? (Arnoud Martens) Re: Lots of zombies with ALPHA-pl13j (Byron Thomas Faber) Re: Can't install Yggdrasil - a workaround found. (Eric Youngdale) Re: Lots of zombies with ALPHA-pl13j (Chris Higgins - System Administrator) Re: /dev not needed? (Alan Cox) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Alan Cox) Re: /dev not needed? (Kevin Brown) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Daniel Quinlan) Re: /dev not needed? (Brandon S. Allbery) IDE/interrupt latency patch (Brad Midgley) Problem with time recorded in wtmp on reboot (Mike Jagdis) Re: Bug in tcpip package? (Brendan Murray) ---------------------------------------------------------------------------- From: ron@argus.lpl.Arizona.EDU (Ron Watkins) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: Linux Astronomy update? Date: 24 Oct 1993 12:43:13 GMT Im looking for the last mail message that went out the astronomy update for Linux. I have recieved a request for information about IRAF and SAOimage which I saw on the last astronomy update. I don't seem to have it in my mail archive though. Could someone please forward that to me again. Thanks, Ron - ron@argus.lpl.arizona.edu -- Ron Watkins [ron@argus.lpl.arizona.edu] / /~~~~) / 931 Gould-Simpson / /____/ / University of Arizona / / / Tucson AZ. 85721 -- (602) 621-8606 (____ unar & / lanetary (____ ab. ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: /dev not needed? Date: Sun, 24 Oct 1993 14:24:42 GMT In article <394.2CC9CBEF@purplet.demon.co.uk> jaggy@purplet.demon.co.uk (Mike Jagdis) writes: >The virtual /proc and /dev filesystems shouldn't be mountable at all. They >should be virtually mounted on, say, \\proc and \\dev just like the root >is mounted on /. Then you can access them as \\proc/1/mem etc. /proc becomes >a symlink to \\proc. Take a look at how many programs hack around /tmp_mnt to get filenames right. For that matter, GNU Emacs and a few other programs contain hacks enclosed in `#ifdef ALTOS' to cope with the old Altos WorkNet (@machinename/path/to/file). And other magic hacks in `#ifdef APOLLO' for their old `//machine/path/to/file' hack. (Also note that both path schemes have been dropped by their respective companies....) You don't want to create magic roots: too many programs know that root is / and blow up if they discover any exceptions. (GNU Emacs will grow pathnames without limit unless hacked, because it's trying to get one that starts with /.) (On the other hand, you also want to avoid magic paths that turn into virtual filesystems; consider what DOS does with a path starting \DEV\...). ++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: martens@dutentb.et.tudelft.nl (Arnoud Martens) Subject: [Q] NTFS for Linux, Anyone ? Reply-To: martens@dutentb.et.tudelft.nl Date: Sun, 24 Oct 1993 14:33:09 GMT Hi, Have there been any attempts to write a NTFS (Windoze NT file system) for Linux. If not so, is there any reason like not being able to get the specs, or is it just that no-one has takn the trouble to do so. Thx, Arnoud ------------------------------ From: bf11620@ehsn3.cen.uiuc.edu (Byron Thomas Faber) Subject: Re: Lots of zombies with ALPHA-pl13j Date: 24 Oct 1993 16:56:36 GMT root@darktower.wastelands.com (System Administrator) writes: >Anyone else had a problem with loads of zombies forming with pl13j? >I've had up to 30 in a 2 hours period from all sorts of sources, and the >PPI is always 0, so I can't track them down. >Here's a sample: >% ps ux [Process list deleted] >roland@cac.washington.edu >-- >=======[ roland@cac.washington.edu ]======================================= >Outside of a dog, computers are a man's best | UCS Consulting > friend. Inside a dog, it's too dark to type.| UW Ice Hockey Co-Captain >================================================================[ LINUX] == There is a reason for calling it Alpha you know. Meaning, it probably has bugs. Byron ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: Can't install Yggdrasil - a workaround found. Date: Sun, 24 Oct 1993 17:01:16 GMT In article kevin@frobozz.sccsi.com (Kevin Brown) writes: >In article <29rjkp$fin@senator-bedfellow.MIT.EDU> tytso@athena.mit.edu (Theodore Ts'o) writes: >> From: kevin@frobozz.sccsi.com (Kevin Brown) >> Date: Sat, 16 Oct 1993 07:24:24 GMT >> >> An interesting thing I've noticed about the behavior of the kernel with >> respect to my MO drive (and this may be generalizable to all removable media >> drives) is that the kernel doesn't reliably recognize that a disk change has >> been performed. The only way I can guarantee it gets it right is by >> removing the media, doing something to access the drive while there's >> no media in the drive, inserting the new media, and then doing >> something to access the drive again. >Well, I tried the program and it didn't do the trick. Naturally a quick >perusal of the kernel source code revealed why. :-) > >The scsi code checks whether or not a media change has occurred by looking >to see if the unit is ready. If it's not, then the scsi code assumes that This is not really true. At boot time it looks to see if a unit is ready, but in general the TEST_UNIT_READY command is not used to detect the media change all by itself. It is true that if the unit is not ready that we assume a media change is taking place, however. The scsi standard requires that whenever media is changed that the unit report an error with a CHECK_CONDITION status and the UNIT_ATTENTION in the sense data. The host is supposed to interpret this as a media change, and can then retry the command. This is the first line of defense for detecting a media change. Anyway, on my CDROM, disk change is automatically detected whether or not you attempt to use the disc without a disc in it. -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ------------------------------ From: chris@csvax1.ucc.ie (Chris Higgins - System Administrator) Subject: Re: Lots of zombies with ALPHA-pl13j Reply-To: chris@csvax1.ucc.ie Date: Sun, 24 Oct 1993 17:14:36 GMT bf11620@ehsn3.cen.uiuc.edu (Byron Thomas Faber) writes: >root@darktower.wastelands.com (System Administrator) writes: >>Anyone else had a problem with loads of zombies forming with pl13j? [...] > >There is a reason for calling it Alpha you know. Meaning, it probably >has bugs. That particular bug seems to be removed from pl13k.. > >Byron Chris. + J.C. Higgins, + Chris@cs.ucc.ie + If you love something, set it + + VMS Sys. Admin, + Chris@csvax1.ucc.ie + free. If it doesn't come back + + Comp.Sc.Dept. + Chris@odyssey.ucc.ie + to you, hunt it down and + + UCC, Ireland + C.Higgins@bureau.ucc.ie + KILL it. + ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: /dev not needed? Date: Fri, 22 Oct 1993 15:34:54 GMT In article <1993Oct19.234432.1474@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >Or, for that matter, the Sun camp. gcc2 binaries for Solaris 2.x are freely >available and work better than any pcc-based compiler anyway. If only a decent version of the kernel for solaris 2 was available. Tried piggybacked data on a syn|ack tcp frame to it. Watched solaris2 acking an rst frame with a wrong sequence.. I think Linux might well be ahead on the networking side too! Alan ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: Fri, 22 Oct 1993 15:51:02 GMT In article drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes: >I don't see the problem - if you are blindly assuming that every >file named core* is a core file, the problem isn't Linux's naming >of core files (agreed apon as the way core files should be named by >the Berkeley Computer Systems Research Group, but too late for 4.4 THe problem is its very hard to write a quick script that removes every 8 hour old core dump and checks it is a core dump by sizes, legal values magic numbers and offsets. If someone writes a little c program isacorefile [filename] Then the script isn't too hard. Alan ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: /dev not needed? Date: Sun, 24 Oct 1993 18:10:53 GMT In article <751242655snxwomble@spuddy.UUCP> sweh.womble@spuddy.UUCP (Stephen Harris) writes: >In article <1993Oct20.134218.18667@excaliber.uucp> joel@rac3.wam.umd.edu writes: [...] >> Also, /dev files must be available on bootup, so you don't want them >> on a mounted fs. My /proc is mounted. > >A bit harder, but not much of a problem. >/ is already mounted without access to the /dev files. >/proc could be mounted in the same way from rc files. >"mount -nt proc /proc /proc" wouldn't need any resources that /dev provides. >"mount -a" would need to be updated to treat "proc" the same way as "root" >(ie put an entry in mtab, but not try to mount) This won't work at all. The root fs is mounted by the kernel, not by some rc script, and it's a special case because it's not mounted on some other directory somewhere (which means that there's no reference count to increment). The killer problem is that you have to be able to fsck your root fs, but you *can't* unless /proc is mounted, and you can't mount /proc without the root fs being writable, and you *don't* want to write to the root fs until you've checked it. Of course, you *could* have a "/dev/root" device with a special major and minor number (say, 0 0) which the kernel understands as being the device file for the root fs. This would have to be a real device file, not a symlink. Then your scheme would work. :-) >[ or heck, do it via a syscall() if you don't really want /proc to do the > job - use syscall() to return an array of name/major/minor devices ] Okay...but how do you open() a filesystem when given just a major/minor device number? Is there some system call which can do this? -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: 24 Oct 1993 20:48:25 GMT Reply-To: quinlan@spectrum.cs.bucknell.edu >>>>> On Fri, 22 Oct 1993 15:51:02 GMT, iiitac@swan.pyr (Alan Cox) said: > drew@kinglear.cs.colorado.edu (Drew Eckhardt) writes: >> I don't see the problem - if you are blindly assuming that every >> file named core* is a core file, the problem isn't Linux's naming >> of core files (agreed apon as the way core files should be named by >> the Berkeley Computer Systems Research Group, but too late for 4.4 > THe problem is its very hard to write a quick script that removes every > 8 hour old core dump and checks it is a core dump by sizes, legal values > magic numbers and offsets. If someone writes a little c program > > isacorefile [filename] > > Then the script isn't too hard. Wouldn't it be easier to use 'file' and write a magic entry for core dumps in Linux? // Dan -- Daniel Quinlan ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: /dev not needed? Date: Sun, 24 Oct 1993 21:37:03 GMT In article <1993Oct22.153454.6160@swan.pyr> iiitac@swan.pyr (Alan Cox) writes: >In article <1993Oct19.234432.1474@kf8nh.wariat.org> bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: >>Or, for that matter, the Sun camp. gcc2 binaries for Solaris 2.x are freely >>available and work better than any pcc-based compiler anyway. >If only a decent version of the kernel for solaris 2 was available. Tried >piggybacked data on a syn|ack tcp frame to it. Watched solaris2 acking an We just went through that in the nos-bbs mailing list. Guess what? Piggybacked syn+data is contrary to the protocol spec: how do you send data when the maximum data size hasn't been negotiated yet? BSD TCP/IP sends data and blindly assumes the other end is all set up to handle it, despite the fact that, so far as the protocol is concerned, the connection is not yet fully set up and data is illegal. And I know of two TCP/IP stacks which adhere to the spec *to* *the* *letter* and therefore reject piggybacked data on a SYN or ACK SYN packet. ++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: bmidgley%sunset.cs.utah.edu@cs.utah.edu (Brad Midgley) Subject: IDE/interrupt latency patch Date: 24 Oct 93 16:32:27 MDT Quite a while ago, Linus was trying to improve the interrupt latency problem in the IDE driver. What he discovered is that some braindead drives required interrupts disabled for long intervals. He changed the driver to work with even these drives. I saw a patch to enable interrupts more often during transfers on the net digest. I was wondering if someone could point out where the patch can be found. ALSO, I'd like to hear success/horror stories from people who try the patched system on their hardware. From what I understand, the "non-compatible" list should be short. Perhaps the kernel could have an obscure macro to enable the improved latency? (obscure so it would only be changed by people willing to take the chance that they'll discover their drive is one of the braindead). thanks -- bmidgley@peruvian.cs.utah.edu ------------------------------ From: jaggy@purplet.demon.co.uk (Mike Jagdis) Subject: Problem with time recorded in wtmp on reboot Date: Sun, 24 Oct 1993 10:26:00 +0000 * In message <2aaqm8$na3@senator-bedfellow.MIT.EDU>, Daniel J Thumim said: DT> There is a problem with how the time is set in linux when DT> the system reboots. The way it currently works is that the kernel DT> reads the hardware clock, ASSUMES it to be in universal time and sets DT> the linux clock to it accordingly. Then init records the time DT> in wtmp, and after that sources /etc/rc (which should fix the time DT> using the "clock" command, according to whether the hardware clock is DT> kept on local or universal time). This causes incorrect behavior, This is a bug in your init. I can't speak for simpleinit but a SYSV init should run all the sysinit jobs as soon as it comes up and before doing *anything* else. The sysinit jobs typically run something like /etc/bcheckrc which is responsible for checking the integrity of the system (fscking root for instance) and performing hardware and related setup (setting the time for instance). Only *after* running the sysinit jobs is init allowed to consider the system useable. If your init doesn't obey this rule then it could, potentially, be nasty. If you have moved to mounting root read only you should simply never get reboot logged in wtmp (since it isn't writable). If you *haven't* moved to mounting root readonly (does SLS do this by default?) then init is writing to a potentially damaged filesystem before you can *possibly* fsck it! Your init needs fixing. Incidentally there *is* another init, the one in the bootsys package. Bootsys is old and buggy now - I saw no reason to continue trying to make it work on every distribution since none seemed interested in using a working SYSV model. Bootsys now forms the basis for the Purple Distribution available from my BBS (+44 734 590990) and others in the UK. Mike ------------------------------ From: brendan@news.otago.ac.nz (Brendan Murray) Subject: Re: Bug in tcpip package? Date: Mon, 25 Oct 1993 02:59:17 GMT Joe Emenaker (jemenake@trumpet.aix.calpoly.edu) wrote: > I grabbed the tcpip.tgz off of tsx-11 down where the MCC stuff is kept. > I got it a few days ago. > Curious thing I noticed: When the install script runs, it asks for ip > addresses in the form of: xxx.yyy.zzz.qqq. However, if I have an ip > address like 129.65.90.12, and I pad it with zeroes like this: > 129.065.090.012, the telnet and ftp programs (possibly others) come up > with some *funky* numbers for the ip address, like 129.51.12.33 or > something. > Has anybody else noticed this? Not with linux - but I know that when I made some files 'tidier' in just this manner in a multinet file on a vax is happily decided to change the base of my numbers ( from decimal to hex I think I recall ) and I had problems all over the place. SO its either a common bug, or correct ( though unexpected ) behavior. I go for the latter. ------------------------------ ** 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 ******************************