From owner-freebsd-arch Sat Jan 2 10:22:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA10558 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:22:21 -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 KAA10540 for ; Sat, 2 Jan 1999 10:22:18 -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 TAA24222 for ; Sat, 2 Jan 1999 19:21:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95540 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:21:53 +0100 (MET) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA23722 for ; Sat, 2 Jan 1999 00:05:43 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id BAA19906; Sat, 2 Jan 1999 01:05:17 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901020805.BAA19906@pluto.plutotech.com> X-To: Joerg Wunsch To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 02 Jan 1999 01:04:59 +0100." <19990102010459.42125@uriah.heep.sax.de> Date: Sat, 02 Jan 1999 00:57:32 -0700 Mail-Followup-To: freebsd-arch@FreeBSD.org From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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