From owner-freebsd-arch Sat Jan 2 10:40:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA12751 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:40:55 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA12746 for ; Sat, 2 Jan 1999 10:40:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24393 for ; Sat, 2 Jan 1999 19:40:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95637 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:40:29 +0100 (MET) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA13445 for ; Sat, 2 Jan 1999 04:20:47 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id NAA20676 for freebsd-arch@FreeBSD.ORG; Sat, 2 Jan 1999 13:20:24 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.1/8.9.1) id NAA13478; Sat, 2 Jan 1999 13:03:16 +0100 (MET) (envelope-from j) Message-ID: <19990102130314.49604@uriah.heep.sax.de> Date: Sat, 2 Jan 1999 13:03:14 +0100 From: J Wunsch To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Reply-To: Joerg Wunsch References: <19990102010459.42125@uriah.heep.sax.de> <199901020805.BAA19906@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199901020805.BAA19906@pluto.plutotech.com>; from Justin T. Gibbs on Sat, Jan 02, 1999 at 12:57:32AM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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