Date: Wed, 28 Nov 2001 21:38:11 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Bakul Shah <bakul@bitblocks.com> Cc: mjacob@feral.com, arch@FreeBSD.ORG Subject: Re: Anybody working on devd? Message-ID: <40211.1006979891@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 28 Nov 2001 12:25:38 PST." <200111282025.PAA03173@wellington.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200111282025.PAA03173@wellington.cnchost.com>, Bakul Shah writes: >May be device nodes should be created by a user process, not >any kernel entity, so that the process can implement any >policy it wants. > [...] This is what I call "DEVFS by simulation", and it has many drawbacks: 1. Complexity. This is actually more code to write and less intuitive to document than doing a DEVFS. 2. Functionality. This doesn't work on a R/O root filesystem or on a filesystem which does not implement device nodes. 3. POLA. If you lack the device node for your root disk, or if your root filesystem is damaged so you cannot remount it RW, you are in a sticky widget: your daemon cannot create device nodes you may need to recover from the mess. 4. JAILS. This almost invariably will cost you a process per jail, something I am trying very hard to avoid. 5. Efficiency. Opening a PTY now needs at least 4 context switches. etc etc. >So I think a user level devd + a device change notification >scheme makes a lot of sense compared to sticking policy in >the kernel. I am trying not to put policy in the kernel (or in the system at all for that matter), what I am proposing is a way to enforce whatever policy the admin wants. For reasons of code complexity it makes sense to do this enforcement in the kernel, rather than add a layer of complexity by sending notices out into userland and back into the kernel before the nodes can be created. I have a paper about all of this for BSDcon2002, but it would be bad style for me to publish it before the conference, so you will have to wait until feb2002 to read it. Sorry. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?40211.1006979891>