Date: Sat, 23 Jan 1999 01:10:32 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901230910.BAA14995@bubba.whistle.com> In-Reply-To: <94808.915113237@critter.freebsd.dk> from Poul-Henning Kamp at "Dec 31, 98 03:07:17 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[Cc to -current trimmed. If you want to have any form of Cc: elsewhere, please keep it a Bcc - moderating a discussion that goes in several fora is difficult. This also implies that I'd like you to not reply to anything Cc:'ed to arch except through the mail you get from the -arch mailing list. -EE] Poul-Henning Kamp writes: > ... to make up our mind about it. > > [ clear arguments for DEVFS and why persistence is complicated ] This email was a few weeks ago, and there was a lively debate, then Julian sent an email listing some issues/requirements, and then the thread kindof died and now we're back to where we were before, which is not any further on.. So I'd like to make another attempt to get agreement on the next step here, so that *something* can happen. We need to get more people using DEVFS, so we can gain some experience & feedback. I don't think DEVFS has any issues that are not surmountable. However, at some point you must take the next step. To do this, we need to come up with a 'next step' that doesn't necessarily make everybody happy, but does make enough people happy that they can use it and it becomes somewhat 'mainstream'... Here's my proposal, which is basically the same thing Poul was suggesting: - Have a non-persistent DEVFS in the kernel; when devices appear they have the default permissions - Have an /etc/rc.devices script to make any site-specific customizations at boot up - Have a mount flag that would disable the appearance of new devices - DEVFS remains a kernel option for now To try and answer some of the issues from Julian's email, in the interest of making decisions so we can proceed: > 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. Devices should appear in the same place (relative to the root of the mount) every time. For now, this path can be hardwired in the device driver. > 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. > ... > 6/ If a process has a device open and it 'goes away', what should happen? No automatic removal of device nodes.. if the device goes away, then operations start returning ENXIO or whatever. After all, this is what a non-DEVFS system would do in the same situation (if it could). > 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. Devices appear with default permissions and ownership... always. "What about a new device that appears when I insert my PCCARD?" Well, you can always do what you do now, which is not have them appear, So at least things get no worse. "Well, actually now I have the device node with my special permissions set already created in /dev, so when the PCCARD is inserted, the device node already exists with those permissions..". Good question.. for now, we ignore this case (and potentially lose a few DEVFS customers). Solving this can be part of the next step. Ideas: (a) have a user daemon; (b) have DEVFS inherit permissions from a 'stub' node of the same name that already exists (if any) when the device appears (then /etc/rc.devices could do its thing for these dynamically appearing nodes as well). > 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? No.. separate nodes are separate files, they just refer to the same device. OK.. so there is some percentage X% of people for whom this proposal would be sufficient to use DEVFS on their systems. Personally, I find it hard to believe that X is not a large number, because for "normal" usage you'd get exactly what we have now, functionally speaking. It seems like this proposal would make DEVFS acceptable for a large percentage of folks.. but definitely not 100% -- and that's OK for a first step. Ultimately, we want to get to a fully DEVFS world. By taking a few steps at a time, and getting people to *use* it, we can eventually discover and address everybody's concerns. Comments?? The issue here is not whether this proposal is a sufficient *final* incarnation of DEVFS, but whether it's a sufficient next step.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com 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?199901230910.BAA14995>