Re: FreeBSD devfs support on NetBSD 5.0

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

On Sat, 20 Jun 2009, David Holland 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.

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

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

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

All I want from a devfs is a filesystem that I can mount over /dev and
have it mirror the internal kernel device node state. There are people who
have posted in the past that don't want that and I can see their valid
security concerns, so such a system should not be required and/or should
be configurable to present a restricted viewpoint. All that is possible,
but first we need a way to monitor the device node table.

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

There is no mechanism for posting notifications to anywhere and it is the
root of the problem.

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

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

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

iain