In message <20041127225340.GB25324@netbsd.org>Bill Studenmund writes


>If you're creating such images, you're creating an image of the root file
>system as part of creation (I'd expect you're shoving it into a kernel
>like what we do for install kernels, but you might do something else).
>So just build into this image a devfs file (of whatever form we end up
>with) that has your devices as you like them. Add a mount flag, and new
>devices don't show up. So you get exactly what you configured.

The dynamic creation aspect -- the need for a separate list of
device-nodes-to-be-created-and-create-permissions, plus the separate
in-kernel code to do all that -- is highly undesirable.

If we can consider for a moment just those applications I'm thinking
of (say, hardened devices running off an in-kernel mfs, as you guessed
earlier) the whole idea of devfs strikes me as unnecessary bloat.
When I put on my security-conscious hat, my first, second, and third
take on the matter are to `Just say No', and to go with persistent
in-filesystem device inodes.  And (amonst people with similar security
concerns) I am not alone in that.

Again, for these hardened embedded systems,I don't care how good the
dynamic-devfs machinery is: for some applications, I *don't want any of it*.

Bill, I don't like to feel like I'm shouting at you, but we seem to be
not-communicating on the actual technical issues. Lets try to talk
offline (phone?), and see if that works better.