Re: FreeBSD devfs support on NetBSD 5.0

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

On Sat, Jun 20, 2009 at 08:08:43PM +0100, Iain Hibbert wrote:
 > > 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.
 > 
 > Well I see what you are saying but unless you think you can change the
 > unix paradigm at this stage, we are stuck with the userland device node
 > namespace being part of the filesystem.  If you have a proposal for a
 > paradigm shift then feel free to start a new thread.

I'm not suggesting a paradigm shift; all I'm saying is that the act of
binding a device into the filesystem namespace is fundamentally a form
of mount... or rather, binding a device into the filesystem namespace
and binding an additional fs into the filesystem namespace (aka mount)
are two forms of the same thing.

There are (currently and traditionally) two separate mechanisms for
doing this. The primary difference between them is that one is static
and the other is dynamic. The goal of devfs or anything devfs-like is
to make the device namespace bindings dynamic... or at least partly
dynamic, since fully dynamic makes permissions transient and there's a
widespread consensus that this is bad.

The conventional approach to devfs is to create a scheme that
dynamically serves the static bindings. This is wrong because it's
duct tape. What I've been arguing (for some ten years now, actually)
is that a far better approach is to unify the two binding schemes.

I've mostly been thinking this in terms of making devices more like
filesystem mounts (more dynamic) but I'm also now wondering if adding
a small dose of making filesystem mounts more like devices (more
static) might yield a better overall model.

I really don't know what you're thinking I'm thinking of, though --
maybe device:path naming?

 > > 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.
 > 
 > Exactly. That is a problem to be solved by those who want to support
 > demand loaded drivers. I don't see what it has to do with representing
 > successfully configured driver nodes in the userland namespace.

Well, yes, except that it's all connected, because people typically
want devices to be demand-loaded when they're opened, and that
involves the namespace.

 > > > 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.
 > 
 > No, the program failed to work because although the device attached just
 > fine (I saw it on the console) it failed to get represented in the
 > userland namespace.  That is the problem that a devfs solves.

I don't understand the failure model then - you saw that it attached
as ugen1 but getting ENOENT trying to access ugen1 didn't tip you off?
Or was the real problem that some piece of "user-friendly" software
was hiding the devices and/or the proper error reporting, so you had
to spend all day trying to read its mind?

 > > (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.)
 > 
 > If it involves rewriting the unix paradigm I can see why you would have
 > serious doubts about it.

It does not, though - neither what I have in mind nor the conventional
devfs approach.

 > > Sure, but a mechanism for posting notifications to userland is an
 > > almost entirely different issue.
 > 
 > There is no mechanism for posting notifications to anywhere and it is the
 > root of the problem.

Yes. That's part of what I was getting at when I started muttering
about automounting, and I probably should have been clearer.

Suppose we solve this problem first and then see if there's still any
mission for devfs.

 > Binding device drivers into the file system namespace does not require
 > dynamic device numbers. Thus, its a separate issue.

No; it *allows* dynamic device numbers.

 > >  > 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.
 > 
 > Sorry but I don't view that as publishing.

http://www.eecs.harvard.edu/syrah/vino/

enjoy.

just keep in mind that it's >10 years old and I've learned a thing or
two since then.

More recent stuff (at least, all that involves any kind of /dev
wizardry) is unpublished in this sense and will probably stay that way
in the absence of large influxes of development funding. :(

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