Date: Thu, 07 Jan 1999 20:51:30 -0700 From: Warner Losh <imp@village.org> To: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901080351.UAA59709@harmony.village.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901080351.UAA59709>