Date: Sun, 03 Jan 1999 12:33:32 -0800 From: Mike Smith <mike@smith.net.au> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901032033.MAA07162@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 01 Jan 1999 22:12:23 MST." <199901020512.WAA09287@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> This may work OK, but there needs to be some way to have an effective > infrastructure to allow this to be changed when the devices come and > go. It still doesn't answer the problems that I wrote about in > earlier messages. Namely if I chown imp /dev/mouse, and then i unplug > the mouse and plug it back in, what should happen? Should it revert > to root ownership? Or should it revert to imp ownership. I think the > latter. What permissions should be retained? This doesn't generalise, unfortunately. There's no guarantee that a new instance of the same device is the same hardware, so we can't make that assumption. If the administrator can, then they need to encode that in their local modifications to the tunable defaults. That sort of "just like a filesystem" semantic is desirable in some cases, but certainly not all, and possibly not even most. > The biggest problem with the current incarnation of devfs is its > inability to deal with devices being added from interrupt context. > Once that is solved, we'd have a good version 0 of devfs. Until a > mechanism can be put into place for dealing with these thorny issues, > making it default (aka version 1) will need to wait. Until version 0 is implemented and deployed, we have no practical basis on which to make the design decisions for version 1. Attempting to make those decisions now, and more to the point, delaying version 0 until we have made those decisions, brings us to the point of gridlock. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.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?199901032033.MAA07162>