Date: Sat, 02 Jan 1999 00:57:32 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901020805.BAA19906@pluto.plutotech.com> In-Reply-To: Your message of "Sat, 02 Jan 1999 01:04:59 %2B0100." <19990102010459.42125@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. I've always felt that much of the machinery of a persistent DEVFS should reside in userland, but that we'd be hard pressed to properly support a dynamic and secure system without persistence. My picture of a devfsd is a daemon with some text based configuration file allowing you to specify dynamic policy (Set the permisions on sa* to root:backup, 0600) as well as record the results of explicit chmod, chown, ln, mv, etc. operations on any DEVFS instance. It would do this via a new 'file modified' poll event type being monitored on all directories of DEVFS instances. There has been talk in the past of adding this kind of poll event for other reasons, but it would be perfect for this application. With this kind of approach, we are free to experiment with different persitence schemes without the underlying DEVFS having to worry about persistence at all. Of course, we need to discuss all of the different mount options that would be needed for chroot type instances and enhanced security (all nodes arrive in the whiteout state by default so they cannot be ls'd, global default permissions, etc). > One disadvantage of a devfsd is that it needs to remain in-core all > the time, or danger of deadlocks could arise. (IMHO) I don't why this would be an issue. Usually these kinds of things crop up in scenarios like halting the SCSI bus without a timeout period from a userland process that mightbe partially swapped out. The kernel should always retain access to configured swap partitions regardless of the activities of devfsd. -- Justin 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?199901020805.BAA19906>