From owner-freebsd-arch Sat Jan 9 13:14:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14727 for freebsd-arch-outgoing; Sat, 9 Jan 1999 13:14:36 -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 NAA14721 for ; Sat, 9 Jan 1999 13:14:34 -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 WAA05431 for ; Sat, 9 Jan 1999 22:13:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA25148 for freebsd-arch@freebsd.org; Sat, 9 Jan 1999 22:13:58 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA24079 for ; Thu, 7 Jan 1999 19:53:42 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zySyv-0006AA-00; Thu, 7 Jan 1999 20:53:05 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id UAA59709; Thu, 7 Jan 1999 20:51:31 -0700 (MST) Message-Id: <199901080351.UAA59709@harmony.village.org> X-To: Archie Cobbs To: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Thu, 07 Jan 1999 19:01:48 PST." <199901080301.TAA03996@bubba.whistle.com> References: <199901080301.TAA03996@bubba.whistle.com> Date: Thu, 07 Jan 1999 20:51:30 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901080301.TAA03996@bubba.whistle.com> Archie Cobbs writes: [[ devfsd and simple protocol ]] You could go one farther, although this might make devfsd mandatory, and have devfs tell devfsd a new device is available, and devfsd then tell devfs to create the device, complete with permissions, ownership, flags, etc. I don't think there would be a need for a NAK protocol. There would need to be some way of dealing with devfsd being killed and restarted (or crashing due to a bug). I'd imagine that new devices would queue up while devfsd was down. Actually, an arrangement like this wouldn't necessarily require devfsd. One could imagine a mount option that says effectively "go ahead and create devices" and another for default permissions if that would be useful. Then in an embedded environment you'd just have a shell script that would fire up on boot, doing whatever chmod you felt like with no need to have a daemon. Especially in a system where no devices can be added after poweron boot. In the running devfsd case, it would need to be run very very early in the boot process. I'd be worried about /dev/console not being present at all and init failing. I think that /dev/console is the only device that init needs to do its thing. If one were hack init, then one could have devfsd fork before init tried to open /dev/console. This would complicate things in the single user mode some what, so I'm not sure what the best approach would be here. Maybe for single user mode /devfs gets mounted in the no daemon mode, and then you get your prompt. Or maybe you'd need to mount it manually first (that seems more like the unix way to do that, come to think of it as not even / is mounted r/w in single user mode). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message