Re: FreeBSD devfs support on NetBSD 5.0

[Iain Hibbert <plunky%rya-online.net@localhost>]

On Sat, 20 Jun 2009, David Holland wrote:

David, I think you are heading way off target and are floundering around
in the bushes.

> (1) Adding (external) objects to the file system namespace is
> fundamentally a mount operation.

# mknod /dev/mynode c 33 44

is not in any way a mount operation

> (2) Similarly, *automatically* adding device nodes into /dev is
> fundamentally a form of automounting.

No, its not. Mounting a filesystem automatically is just that, mounting a
filesystem. We don't have any way to find out that a device containing a
filesystem exists to be mounted and THAT is the hurdle that needs to be
jumped first.

> (3) There are some inherent and fundamental problems with trying to
> support both demand-loaded drivers and automatic name insertion into
> /dev.

IMHO that is a problem to be solved by those who want to support demand
loaded drivers, but autoconfig could report unconfigured drivers just as
well as configured drivers and allow a separate process (kernel or
userland) to make the decision to look for a driver.

> One possible way is to make a list of every possible openable device
> driver and its name, and use that to drive load and probe/attach on
> open. However, that's what we already do: the list is called /dev.

Not really - I plugged my camera into my new laptop and spent all day
grobbling through the internals of libusb trying to find out why I
couldn't get to the pictures. In the end I found it was because there was
no /dev/ugen1.?? device nodes - this laptop has a built in fingerprint
reader attached to ugen0 :-/

> (4) Structurally, permissions are (and should be) properties of the
> device driver, not of some intermediate devfs object. Some devices
> have (or should have) fixed permissions; for example, "chmod 711
> /dev/null" serves no purpose but to render the system dysfunctional
> and there's no need to allow it at all... let alone go to a lot of
> effort to make its effects persistent.

I would prefer if absolutely no effort at all was made to handle special
cases like this. If an admin wants to shoot themselves in the foot then
I'm ok with it.

> (5) I still don't like the idea of kernel systems that require a
> service daemon.

sure thats something we can [all] agree on

> And finally, I'm still not entirely clear on what the benefit of a
> devfs is supposed to be.

see my camera issue above.

also, when you have a notification method for new devices, a userland
daemon can be written to listen to them and do the right thing. In truth,
although you say that automounting is difficult, it is something that most
people want to be able to do and it would be good if NetBSD could allow
that at least.

> The devfses that I've implemented have allowed eliminating
> cdevsw/bdevsw and using purely dynamic device numbers strictly for ID
> purposes. This has certain maintenance benefits.

Yes but that is a separate issue. As I said, I think that lumping several
things together under the roof of 'devfs' is wrong (and doomed to fail).
Unix works with small simple tools that do one thing well and I think its
a good design to carry forward.

As I said, I'd be happy with a simple daemon that could listen to
autoconfig notifications and create/remove device nodes dynamically in the
first instance. That leaps the first hurdle and allows people to create
different implementation features.

However, I didn't write any code. If you have written some then please
feel free to publish it. Ditto for Hans and ditto for Matt.

iain