Date: Sat, 2 Jan 1999 01:04:59 +0100 From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <19990102010459.42125@uriah.heep.sax.de> In-Reply-To: <94808.915113237@critter.freebsd.dk>; from Poul-Henning Kamp on Thu, Dec 31, 1998 at 03:07:17PM %2B0100 References: <94808.915113237@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
As Poul-Henning Kamp wrote: > I talked to Dennis Ritchie about the history of device nodes > (CHR/BLK) when I ate breakfast with him in New Orleans. :-)) Nice sentence, too bad I haven't been able to attend in NO myself... > The advantages of having a DEVFS is trying to solve are the following: Violent agreement. > NON-PERSISTENT DEVFS: Let me add here for those who don't know the story yet, I had the opportunity to work with a system with a non-persistent DEVFS quite some years ago. The overall experience was very positive. The system in question was DG/UX, Data General's Unix version running on their AViiON class of machines, some m88k-based workstation/server series. DG is mostly down these days, concentrating on things like RAID arrays for Winsucks. Too bad, i've seen source code of the DG/UX kernel, and think it was a well-written system. My remembrance is fading, but I believe it took me more than one year to actually even _realize_ DG/UX was using a DEVFS. Count this as an argument for them having done the job very well. Again, their DEVFS didn't have any form of persistance, everything regarding device ownership and permission tweaking was done in some rc script. (The kernel had hard-coded ideas of the initial device permission bits, so something like /dev/null always came out world-writable even with no rc script running so far.) > If you remove a device, it's gone. No way to get it back > short of a reboot, and it will be back after the next reboot > if the driver is there and finds its hardware, so to remove > a device as a policy, you would need to put the rm command > in /etc/dev.rc. If you "whiteout" a device, you can get > it back with "undelete" and don't need a reboot for it. I don't see any form of an implementation for `whiteout' and `undelete' so far. I don't particularly like the idea that you can thus destroy a device access point accidentally. I'd like to see some method for the sysadmin to tell the kernel to `go back and re-establish its idea of the DEVFS'. Speaking in implementation details, it could be another option bit to reboot(2), with another hardlink to reboot(8), like perhaps /sbin/reconfigure. Perhaps this should only go so far to re-established any device node (or its substitute) that has been removed, without resetting ownership and/or permissions on things that are still alive. > SOME of the issues not addressed in this description: > > * format of persistance database: ascii file, binary file > shadow inodes ? If at all (readers might notice I'm not much a fanatic of persistence here ;), then it should be an ASCII file somewhere. By no means, it should be recorded in some unmanipulatable form. I could also imagine of some `unionfs' layer you could mount separately so to see what its current contents is. However, I believe this will only complicate things. > We have had a DEVFS implementation in the tree for 32 months by > now. That means from before 2.0.5 was released. The reason we > still don't have a DEVFS as standard is that this persistence vs. > non-persistence has not been sorted out. It is high time to > get this thing settled and move on. Well, one question sideways: does this mean all the problems with disks entered after boot-time have been resolved in the existing implementation? I. e., I can say `camcontrol rescan all' (or scsi -r on an older system), and it will pick up anything like dreadful fdisk tables and BSD partition tables without a whisper? Last time i looked, this wasn't the case, and my attempts to walk down the code and get it working (on a NFS-booted machine, should that matter) weren't all that successful. [This does not presently work. Julian had/has some partially finished code to fix it. -EE] > OPINION: > > My personal preference is to take a non-persistent DEVFS. Mine too, but that should have become obvious so far. Thus, I fully support your reasoning as you explained in the `non- persistent' section. Persistency aspects: > I would need to be able to edit or at the very least read the > persistence database (sound of agonized cries from AIX users heard > in the background). How would I edit an entry in the persistance > database for a device I do not currently have in my system ? What > happens if I edit the database and somebody else does a chown at > the same time? Stop the devfsd, edit the database, restart devfsd. > Can I add dormant entries to the database so that > any devices appearing later will be set according to my policy? That should be possible, but you're right, it will add complexity. It should by no means go into the kernel. > It is obviously out of the question to implement the full shell > syntax in the kernel, so either we need a special userland process > to translate to and from a standard format, or a special toolset > to list/edit the binary database. One of the major proponents of a persistent DEVFS was Justin, last time we've been talking about it. It seems Justin's opinion is now also to put all this out to userland, into something like a devfsd. One disadvantage of a devfsd is that it needs to remain in-core all the time, or danger of deadlocks could arise. (IMHO) > How about the case where people try out some gadget, forgets about > it for a number of months and buy some other gadget instead which > the same driver recognizes, then sudenly some old stuff appears > out of nowhere which may not even apply to that device, and since > the device is there in the database, not even the device driver > gets a chance to say what it feels about the issue ? In AIX, it would have become instance #1 for the new gadget, with keeping the old instance #0 in mind for eternity. :-) But point taken, you're right. It was a pain in the butt to move some Ethernet card around from one MCA slot to another in AIX. > How many people would ever know the difference anyway? Very few, > I presume. I agree. See my experience report with DG/UX. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990102010459.42125>