From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sun, 24 Oct 93 00:13:11 EDT Subject: Linux-Development Digest #183 Linux-Development Digest #183, Volume #1 Sun, 24 Oct 93 00:13:11 EDT Contents: Re: UNIX trademark now X/Open (Brandon S. Allbery) Re: Libc 4.4.4 and new sig 11's (not ram chips) (John Henders) Re: Can't install Yggdrasil - a workaround found. (Kevin Brown) CALL FOR SUBMISSION: Linux Distribution-HOWTO (Matt Welsh) /dev not needed? (Mike Jagdis) ---------------------------------------------------------------------------- From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: UNIX trademark now X/Open Date: Sat, 23 Oct 1993 13:28:09 GMT In article <2aagpd$af0@news.u.washington.edu> kenney@stein1.u.washington.edu (Michael Kenney) writes: >If it's a new OS you're after, it's probably better to start with a clean >slate - a full redesign. > >A free Plan-9 anyone :-). Don't laugh. If you stop and think about it, there are some remarkable similarities between the concepts of Plan 9 and Microsoft At Work... ++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: jhenders@jonh.wimsey.bc.ca (John Henders) Subject: Re: Libc 4.4.4 and new sig 11's (not ram chips) Date: Sat, 23 Oct 1993 14:26:21 GMT jbettis@cse.unl.edu (Jeremy Bettis) writes: >Add to the list of programs now broken under 4.4.4: getty_ps. It keeps >trying to initalize my modem over and over again ever since I installed libc >4.4.4 Actually, getty_ps seems to have been broken for a while. I had a working version compiled under 4.4.1 with 99pl6 but when I was trying to get dialin's working recently (they worked last spring, but I haven't used them much) a recompile with 4.4.2 and 99pl12 definately does not unblock. It doesn't respawn like it seems to under 4.4.4, but it doesn't work. I'm going to reinstall the 4.4.1 library code and see if it works there. Attempts to contact Kris Gleason, the linux maintainer of getty_ps, have so far failed. -- John Henders GO/MU/E d* -p+ c+++ l++ t- m--- s/++ g+ w+++ -x+ Segments are for Worms ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Can't install Yggdrasil - a workaround found. Date: Sat, 23 Oct 1993 17:39:25 GMT 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. > >The kernel can certainly determine this for (non-SCSI) floppy drives; I >don't know if the problem is that your MO drive isn't sending the disk >change event to the SCSI adaptor, or that the SCSI code doesn't deal >with disk changes, and so isn't passing it up to the buffer cache layer. >I haven't had a chance to look at the SCSI code myself. 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 a disk change is in progress and sets itself up such that, on the next check, it will say that a media change has occurred regardless of whether or not the unit is ready. It then reports that a media change has occurred, in order to cause the associated buffers to be invalidated (since at this point there is no media in the drive). It doesn't seem to do anything at all with respect to disk change events, if such a thing is supported by the SCSI protocol at all. The SCSI code for handling CD-ROM disk changes is essentially identical. So: if you're running a removable disk device on your SCSI bus, you have to access the device while a disk is out (or while the unit is somehow rendered not ready), and then access the device when the new disk is in, for the code to detect that a disk change has occurred. Probably the easiest way to do this so that the partition table will automatically be re-read when a disk change is performed is by polling the removable drive. Just opening it for read is sufficient to cause the code to check for a disk change. Polling the drive once every couple of seconds or so should be sufficient. The only problem is that, while there's no media in the drive, you'll get a bunch of kernel messages saying that the device isn't ready. Sigh. But I run X-windows, so such messages are invisible until I switch to a real console. :-) -- 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: mdw@sunSITE.unc.edu (Matt Welsh) Crossposted-To: comp.os.linux.announce Subject: CALL FOR SUBMISSION: Linux Distribution-HOWTO Date: 23 Oct 1993 19:57:43 GMT Attention: Maintainers of Linux software distributions and other mail order services. This message explains the upcoming Linux Distribution HOWTO and what you must do to be included in it. Please note that ALL Linux distributions and mail order services *MUST* be included in the Distribution HOWTO to be announced on comp.os.linux.announce, the primary source of Linux news for USENET readers. Please read on for details. The Linux Distribution HOWTO has been on the back burner for some time, and I'd like to get it finished and out of the way. The purpose of this document is to contain, in a single posting, information on all of the distributions and other services for Linux which are available via mail order and anonymous FTP. The document includes: * Distributions of Linux software (floppies, tapes, CD-ROMS) * Technical support for Linux * Books and other information related to Linux * Other services and goods such as T-shirts and virtual beer The Distribution HOWTO is for both mail-order and FTP distributions of Linux; if you spport a distribution of Linux which is not available via mail order, you should include information on it in the HOWTO as well. This of course only applies to complete "distributions" of Linux; I'm not talking about individual software programs that people are porting and working on. Distributions are things like SLS, MCC-Interim, the Yggdrasil CD-ROM, and so on. The current Distribution HOWTO by Bill Riemers is not quite sufficient; it is for this reason that I have not officially released it. The point of this document is not to simply duplicate all of the README's and announcements of these various services, but instead to summarize their availability into a nice document that people can refer to as a source for all kinds of Linux services. Another goal of the Distribution HOWTO is to get the individual postings for these services out of comp.os.linux.announce. The Distribution HOWTO will be of course posted to c.o.l.a (as well as many other places), but I feel that currently the tendency is to post a biweekly "advertisement", some of these I have turned down. In order to keep everyone on equal footing all mail order distributors of Linux will be required to include information in the Distribution-HOWTO. After the Distribution-HOWTO is ready I will NOT accept any individual postings for mail-order Linux services. (Except in the below cases; please read on.) I will accept, however, individual announcements of the following: * Announcements of new versions of a Linux distribution. That is, Peter MacDonald will be allowed to post information on the new releases of SLS, (including mail order info if he wishes), because he maintains SLS and it is of interest to the community when a new version is released. However, people who simply re-sell SLS on floppies will not be allowed to make individual announcements to c.o.l.a; they must be included in the Distribution-HOWTO. * Announcements of a new service which is not yet included in the Distribution HOWTO. That is, the first time a new service becomes available, an announcement may be posted to c.o.l.a. Thereafter, all subsequent announcements must be included in the Distribution-HOWTO. In other words, just about the only thing that I will reject is postings from people who are re-selling an existing distribution of Linux in some form, or from people providing services not related to a software distribution (such as technical support). Unless you actually maintain, update, and support a distribution of Linux, you will not be allowed to make individual postings to c.o.l.a to advertise your mail-order service. YOU MUST INCLUDE INFORMATION IN THE DISTRIBUTION-HOWTO INSTEAD. I will make exceptions to the above policy; if you have an unusual or unique service or situation, please talk to me. These rules are not hard and fast; they're only meant as guidelines to round out some of the competition in the commercial Linux world. AND NOW FOR THE GOOD STUFF. To be included in the Distribution HOWTO, please mail me (mdw@sunsite.unc.edu) a message of the following format. This is not a machine-parsable format; all of the "fields" may be any length. Please keep the entire entry down to, say, 50 lines if possible. If you need to say more, please include a pointer to where one can find more information (such as the location of a README file on some FTP site). Name: Distributor: Description: Availability: Ordering: Miscellaneous: Please keep your entry as short as possible. In addition, please use SEPARATE ENTRIES for each service/distribution that you provide. For example, if you provide both a distribution of software and technical support service, please use a different entry for each. (They can be mailed together or separately, I don't care). Some things (such as books, t-shirts, etc.) won't fit exactly into this entry; just be sure to include all relevant information. In other words, this "entry form" is simple the bare minimum that you must include in your submission to the Distribution-HOWTO; feel free to change, add, or leave out "fields" as you see fit. Here is an example entry: -- Name: ShoopWare Distribution v1.0 Distributor: Virtual Pizza, Inc., goober@shoop.vpizza.com Description: The ShoopWare distribution is an all-new distribution of the Linux operating system together with the "vpizza" software development platform. This software allows you to develop applications for pizza delivery services on the Internet. The distribution itself is based on SLS v1.03 and uses Linux kernel version 0.99.pl13. Other software included in the release includes XFree86 1.3, Emacs, TeX, TCP/IP networking, and more. The release is distributed on 42 floppies (for the full system), each floppy may be installed optionally. Availability: ShoopWare v1.0 is available via anonymous FTP from shoop.vpizza.com in the directory /pub/ShoopWare. Ordering: n/a (this is only an FTP distribution) Miscellaneous: Mail goober@shoop.vpizza.com if you have questions or comments about this release. -- I will more than likely edit your entries to some degree if I find any irrelevant information, or if the entry is overly verbose. Otherwise the content should remain the same. I'd also like your permission to use the entries in the Distribution-HOWTO in other Linux documentation, including manuals from the LDP, and other materials. For example, if we ever have the opportunity to publish a Linux book, this information would be an excellent source of Linux services and distributions to include in this book. I would simply like explicit permission to redistribute the information in the Distribution-HOWTO as I see fit; the Distribution-HOWTO itself will be copyrighted by me, and licensed under the GPL. If you have any questions about the Distribution-HOWTO, or this posting, please mail me at the above address. I'm more than willing to discuss aspects of the new policy; this is not set in stone! Thanks, mdw -- Matt Welsh, mdw@sunsite.unc.edu ------------------------------ From: jaggy@purplet.demon.co.uk (Mike Jagdis) Subject: /dev not needed? Date: Sat, 23 Oct 1993 10:54:00 +0000 * In message <751242655snxwomble@spuddy.UUCP>, Stephen Harris said: I was playing with the device code a while back looking at ways of implementing cloning devices, /proc/dev access etc. I don't have the code anymore (it was just a cheap 'n nasty proof-of-concept hack). But some interesting thoughts came out of it. SH> 1) symlink /dev to /proc/dev SH> 2) symlink contents to /proc/dev into /dev SH> 3) COPY contents of /proc/dev to /dev SH> 4) /proc/dev is in fact a LIST of devices the system knows, SH> and this is used to mknod the devices in /dev at boot time. /proc/dev is quite nice. There are complications however. Firstly dont' try and put it under /proc. Make a new virtual filesystem. You probably want to use the device's major/minor pair as an inode number similar to the way the process entries work and the process entries already soak up 16bits of the inode space. Alternatively you could go for a more complex mapping... Permissions are another problem. The initial permissions either need to be set up when the device is registered (and hence hardcoded in the driver code) or there needs to be a boot script that changes them. Either way the permissions on device files behave differently from what many might reasonably expect. Oh, and as far as dynamic majors go it isn't difficult for most drivers to simply note down what they get back from register_xxxdev(). The biggest problem I saw was the general block code which wants to set up from majors defined at compile time rather than determined at run time. I didn't look in to this too closely though. You don't *have* to do dynamic majors. Dynamic minors are no problem to anything except the drivers you want to handle them. SH> > Also, /dev files must be available on bootup, so you don't want them SH> > on a mounted fs. My /proc is mounted. SH> A bit harder, but not much of a problem. SH> / is already mounted without access to the /dev files. SH> /proc could be mounted in the same way from rc files. 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. To do this you need to mount them at the same time as root is mounted in super.c (not too difficult). Then in the VFS namei.c you need to trap paths that start with '\' (or '\\' or whatever). There is already a trap there to catch paths that start with '/' and start the search from the root filesystem. Do the same for the, ah, "magic" filesystem(s). Don't worry about mtab. It isn't relevant to anything you can do with /proc. You don't even care about unmounting those things before you reboot. Actually it hadn't occurred to me before that /proc could be made a symlink to \\proc or I might have offered up a patch - I was thinking of other things at the time. Having a root and a "magic" root would need people to change their boot scripts (or could it be worked around?) but sounds like a reasonable half step forward? Maybe Linus is listening? Mike ------------------------------ ** 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 ******************************