Date: Sat, 9 Jan 1999 14:39:04 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: arch@FreeBSD.ORG Subject: DEVFS Message-ID: <Pine.BSF.3.95.990109141042.8699B-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
Sorry if this is late, but I only discovered by accident that there had been a big discussion about DEVFS in the "arch" mailing list and it appears that my original subscription either failed or got clobbered.. Anyhow: >From what I gathered.. The point was raised that it's time for DEVFS to either be finished or be replaced by an equivalent item that is finished. Since the main part of DEVFS was ripped out by the throat by dk.com it has been waiting for me to either take it out or fix it again. It would be nice if we could agree on some things or at least discuss them. I have not given up on devfs, but I've been a bit dispirited by the lack of support. DEVFS is just fine as it is for non-disk devices, but it needs the SLICE code (or an equivalent) before it can really be useful. (more on this at the end). SLICE was waiting for CAM to come in so I could apply a bunch of changes that were CAM specific. It replaced the 'in-line' registration and probing of devices with a kernel daemon that managed all devices and did these things in a way that allowed a context to be associated with the IOs. This simplified a lot of things. It was also needed for devices (such as CAM supplies) that have arrival and departure events. OK, so assuming that DEVFS gets rev'd to the next version or even replaced, here are some things to think about: 1/ Every driver needs to add it's entries.. What I have added to each driver would probably do or be close, for almost any devfs implementation with maybe minor mods. There are only so many things you can need to provide.. 2/ The filesystem needs to be able to create multiple instances of itself for chroot systems etc. 3/ The filesystem needs to give a method to allow new devices to appear as created. If the layout of a /chroot/dev filesystem has been changed, then you need to work out WHERE in the filesystem to create the new device. 4/ If a user changes the name of a device or makes a link to it, those devices must still be removed when the device becomes invalid. 5/ If a device has its modification time changed, does that change reflect through all instances of that device? (E.g. /dev/xxx and /chroot/dev/xxx). What about permissions? What about ownerships? 6/ If a process has a device open and it 'goes away', what should happen? 7/ Persistence is I think a WOFTAM. Some people want it. It could be ignored in my opinion but you should at least have a scheme in mind.. My suggestion is to pick up permissions and owners from inodes of the same name read from the filesystem on which the devfs was mounted. A synthetic / filesystem (An idea that I know Poul has been kicking around for a while) wouldn't be able to do that, but there are other ideas I guess. 8/ There should eventually be built in, a way of getting directly from the DEVFS entry to the driver. The present DEVFS bypasses the bdevsw table, but still goes via the devsw entry itself. This may be acceptable. We might as well get the requirements worked out. After all we have a couple of years of experience with this now.. The reason for the SLICE module comes from the need to be able to support hierarchically organized structures of 'disklike' devices. Disklike devices include parts of disks and concatenations in various manners of disks. They also include 'value-added devices" such as a layer that lies above a disk and remaps bad blocks, or, possibly supplies a service such as encryption. The present system relies upon the 'open' code to force a scan of the disk devices and thus cannot supply the subdevices until they are opened. A chicken/egg problem. There is a hack that works for the root disk, and disks present at boot, but doesn't generalize. The present system is also "locked" into handling only the three formats "raw disk, fdisk, and disklabel". Extending it to handle CD-ROM partitions and Macintosh partitions would be a major rewrite. This suggests that the present system needs either a radical update or replacement. If we need to rewrite it anyhow for production of subdevices as the device 'arrives' then we might as well generalize it to be able to support arbitrary 'organizing layers'. Thus SLICE was born. DEVFS doesn't really need it, but the rest of the system needs it to be able to use DEVFS correctly. As it's totally dynamic, it of course needs DEVFS because a repartition of the disk may mean the need to produce new device nodes. The reason for DEVFS is that it is dynamic, and allows for a totally dynamic kernel. These "disk-like devices" are also dynamic and there is really no good way of representing the many combinations that can be produced in a static system (such as the present major/minor system). Personally, I'd much rather work WITH someone on DEVFS, but so far there has been a lot of criticism and no help. Interestingly, the LINUX devfs is already at the stage that ours is, but is similarly stopped at the point of needing something like SLICE. Their disk system, however, is not hierarchical in the manner that ours might be so, they don't see the need to support hierarchies of formats (e.g. vinum on partitions of slices). Anyway I hope we can have some discussion on what a devfs should achieve, and then we can see if the present system can do it or maybe it needs a complete rewrite. My main aim is to make FreeBSD be more dynamic and less static. If someone else sees a better way of doing this then that's OK by me. BTW: What happened to Poul's work to remove block devices entirely? Julian 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?Pine.BSF.3.95.990109141042.8699B-100000>