Re: FreeBSD devfs support on NetBSD 5.0

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Jun 20, 2009 at 11:02:37AM +0100, Iain Hibbert wrote:
 > David, I think you are heading way off target and are floundering around
 > in the bushes.

Nope :-)

 > > (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

mknod isn't, but what does that character-special node do? It binds a
foreign object (a device driver) into the file system namespace. It
doesn't do it by mount as such, because 'special files' are a
long-standing alternative hack for handling these bindings. But it's
still a binding and it's still the same kind of binding as a mount.

Traditionally in Unix devices are not themselves vnodes, but there's
nonetheless a simple mapping between vnode I/O operations and device
I/O operations.

If you still don't see it, step back a bit until you can see the
forest as well as the trees.

Yes, you can make a devfs that does nothing but automate the mknod
operations. It's the wrong architecture, for the reasons already cited
and because it's adding a second hack on top of a previous hack
instead of designing a solution. And it still has most of the same
issues as automounting, which don't arise from the details of how the
name-to-object binding is created.

 > > (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.

Unconfigured drivers known to autoconfig are still only those that
have been already loaded, or at a minimum those where knowledge of
existence and attachments have been loaded in. I guess you could poke
the kernel somehow to have it reload that data if you install a new
driver.

Having a userland process involved in serving name requests in /dev is
not a good idea. You're really getting into automounter territory
there, complete with all the attendant problems like deadlocks and
hanging the system if the daemon hiccups.

Anyway, I'm not all that excited by demand-loaded drivers, but other
people are and the issue needs to be resolved in some fashion.

 > 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 :-/

So you're saying that you'd be more likely to notice an extra handful
of names silently appearing in /dev than the string 'ugen1' appearing
in dmesg? Forgive me if I'm a bit skeptical.

(And, by the way, I don't disagree that it would be nice to have this
kind of thing work better; I just have serious doubts about the devfs
approach.)

 > > (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.

Sure. The question is whether effort should be expended just to allow
this to happen. I don't see that it should be. Meanwhile, while some
device nodes do need chmod support, the default permissions for most
of them (which are never changed 99% of the time) are inherent in the
device, and it would make more structural sense to place them (plus
any chmod support) there than having to handle it independently in
some devfs config system.

Plus, there are a number of other possible uses for persistent device
properties.

 > 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.

Sure, but a mechanism for posting notifications to userland is an
almost entirely different issue.

 > > 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).

It's not a separate issue; it's all about binding device drivers into
the file system namespace.

 > 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.

That sounds entirely preferable to doing the exact same thing inside
the kernel.

 > 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.

I have, but it's not for NetBSD. Again, if anyone wants to look at it,
mail me.

-- 
David A. Holland
dholland%netbsd.org@localhost