Date: Sun, 03 Jan 1999 12:42:11 -0800 From: Mike Smith <mike@smith.net.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Chuck Robey <chuckr@mat.net>, arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901032042.MAA07212@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 02 Jan 1999 11:36:45 %2B0100." <6040.915273405@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > From: Chuck Robey <chuckr@mat.net> > > > > First, Poul, will you agree that the opinion of the great majority of > > developers want persistence? > > No, I will not. It's irrelevant whether you agree or not. Most of the ones that have expressed a concern see the ability to control the behaviour of the DEVFS as desirable. Many of those schemes don't really qualify as "persistence" per se, but attempt to address the same set of problems. More to the point, we have on record some very strong sentiment from the user community (remember them?) indicating that the ability to address these problems is very important to them. > > From: Mike Smith <mike@smith.net.au> > > > >> 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'. > > > > My personal preference for this is for it to be handled by mknod. The > > mknod(2) syscall would un-whiteout a device node (or nodes), allowing > > you to bring them back from the dead (perhaps modulo securelevel). > > But if you think about chroot for a moment, it will be obvious to > you that we need a way to hide (whiteout) and to destroy for good > (unlink) a node. You would not want it to be possible to bring > them back in a chroot jail. Agreed, that could also be handled > by the same mount option which says "show me no new devices". Lets > bag this point as an implementation issue. It is not material to > the persistence/non-persistence debate. You _might_ want it to be possible to bring nodes back in a chroot jail, since chroot jails are used for considerably more diverse purposes than simply security. Hence the need (as you've already divined) for both 'whiteout' and outright permanent revocation. However, as you point out, this is indeed an implementation issue. > The question remains more or less: > > Do we want a "chmod 764 /dev/foo" to be persistent over reboot, > despite the significant amount of code it takes, and the potential > to pop out of the blue six months later and bite people ? I don't see a clear need to emulate things to this level. A mechanism where it's possible for the administrator to say "I want all sio* devices to come up 664 root/dialer" is more than adequate for the majority of cases. Peter's class model works for this; think of it like a 'umask' for devices. > I think I hear Mike Smith saying: > > "I want persistence for persistence sake" Thanks for the slap. No, I want tunable defaults as a practical alternative solution to the problems that persistence tries to address. I don't think we have enough mileage on the devfs scenario (trivial anecdotes aside) to make any hard design decisions at this point in time. -- \\ 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?199901032042.MAA07212>