Date: Sat, 2 Jan 1999 13:03:14 +0100 From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <19990102130314.49604@uriah.heep.sax.de> In-Reply-To: <199901020805.BAA19906@pluto.plutotech.com>; from Justin T. Gibbs on Sat, Jan 02, 1999 at 12:57:32AM -0700 References: <19990102010459.42125@uriah.heep.sax.de> <199901020805.BAA19906@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Justin T. Gibbs wrote: > 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. I feel I could live with _that_ way of persistence rather well. It would also allow for both implementations to compete (a persistent one via a devfsd, and a hand-edited policy description via rc.devfs) for some time, in order to see which one might be the best. Regardless of which one we choose, the kernelland is about the same and any required details about the kernel part of DEVFS could be clarified quickly, so necessary actions (like possibly revamping the entire kernel implementation should this be required) won't be deferred again for a long period. I take it from all the people who raised their voice so far that all are in happy agreement that DEVFS should become the future standard (and since it has been deferred for too long already, this should be done in something like 3.1-RELEASE)? This was one of Poul-Henning's questions, too. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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?19990102130314.49604>