Re: (Semi-random) thoughts on device tree structure and devfs

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

> What kind of user do you talk about here?

This is a good question.

When I speak on netbsd lists, I have following in mind:

a) Desktop users

They use NetBSD for browsing www, reading/writing mails, playing videos,
doing math, studying, text processing, etc.  They use a variety of machines,
typically notebooks/netbooks and commonly seen x86 platforms.

b) Server users

They use NetBSD for mission critical, high-performance servers like high-load
network servers, I/O servers, etc.  They use multi-cpu high-performace machines
with multiple network / disk interfaces.

c) Embedded users

They use NetBSD for production like routers, printers, cellphones, various
home electronics, robots, factory machines, cars, trains, ships, airplanes,
submarines, spaceships.  They want small and reliable systems.

d) Hobbists

They run NetBSD on old machine like VAX, Alpha, m68k, SH, PowerPC, MIPS, some
production NAS or routers.  Most of them are slower than others.  They like to
hack NetBSD source code.

*

I'm a little biased to c), because I'm it myself, but I think all of these
users are equally important.

> > - Predictability / stability
> > 
> > Device numbers don't change surprisingly.  When you plug device A and B in
> > slot 1 and 2, they should be shown in that order.  When you add disk B @ 
> > slot
> > 2, the number of disk A @ slot 1 must not change.
> 
> Wrong.  Device numbers should be irrelevant to anything but operations
> on device_t objects.

I don't understand.  Could you elaborate this?

> This has nothing to do with what devfs is about.  If your idea of devfs
> is that the user should know the whole device path to access a hard
> drive, you have strange ideas about simplicity.

There're some devfs implementations around, and AFAIK there's no standard, 
right?
I came up with my design by myself.  So my devfs follows the design of my devfs.

The overall intent is to concentrate the information into the device tree,
where we can identify *all* the instances of devices, including ones that
don't have any IDs like GUID or MAC address.  Each node exactly matches
device::dv_xname.

I don't want to make this more complex, like give drivers freedom to decide
how they look like.  That leads to lots of code added around drivers
(xxx_register / xxx_deregister), like mjf's proposal did.  My devfs doesn't
do that for consistency and simplicity of the implementation.

As pointed out by all of you, the device tree of my devfs can't lookup device 
IDs.
That could be easily realized like

        /dev/id/guid/25892e17-80f6-415f-9c65-7395632f0223
        /dev/id/guid/a53e98e4-0197-4513-be6d-49836e406aaa
        /dev/id/ieee802mac/00-b0-d0-86-bb-f7
        /dev/id/ieee802mac/00-a0-c9-14-c8-29

But what it does internally is to lookup ids in the device tree iterating like:

        devfs_readdir()
        {
                foreach (alldevs) {
                        if (device_attr_has_guid_p(dev))
                                uiomove(dev, result);
                }
        }

Because struct device is the identity of device instance.  I don't think it's
worth doing in kernel.  It's not different than fts(3) the /dev/mainbus0 and
ioctl it or open/read some form of metadata file.

If you want more user-friendly representation like:

        /dev/dk/dk0.<guid>
        /dev/name/my backup usb disk \#1

I think that's truely beyond kernel's responsibility.

> Are you really just discovering that wscons needs a lot of love?  It's
> old news.  The problem is that nobody wants to deal with that mess and
> the ensuing binary compatibility nightmare.

Is that all?

> It seems to me that you are really confused, about a number of things.

Not at all.

> Out of those, the most important is what the user experience should be,
> so let me be clear on this:  the end user should never, ever, ever deal
> with monstruosities like a full device path.

End users don't need those full paths.  Like other exposed paths like /etc,
/var, /usr.  PID/PPID is already exposed to users.  What is different?

> And device paths are not devfs, okay?

I don't know your devfs.

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635