tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Is it just me who find this whole ide ironic?

Have everyone forgotten how to set up their own kernel? Is everyone now booting GENERIC? (Or just making a copy of GENERIC, with a few patches without understanding what they are editing?)

The whole point being that if you boot a kernel, in which you have configured the whole system to connect anything anywhere, you should not be surprised if the device enumeration might seem random. If you want predictable device enumetaion, you can have that, and have been able to have that for over twenty years...

The line
wd*     at atabus? drive ? flags 0x0000

(to use one example) says that match any wd type disk to any unit number on any atabus, without doing any closer matching. Ie. kindof unpredictable.

The asterisks and question marks means exactly that. If you want predictable matching that stays the same at every boot, no matter what hardware you put on the system, you write explicit lines in the config instead.

Jeezuz! How have we fallen to these lows? Trying to make a filesystem that shows the hardware configuration, with absurd, long and silly paths, which is pretty useless anyway, since if we just move the disk the slightest, we lost it anyway. For basically no gain in functionality, a lot of new mess to deal with when managing the system, and a lot of work...

I can see a point in having a way to express a specific disk, based on a disk label instead of the hardware, since that would actually be useful.

The idea suggested by Masao looks to me like a lot of cruft that will break away even farther from the original simplicity of Unix, for ny actual gain.

But I guess I'm a grumpy old fart, who thinks so already anyway.

NetBSD... A system that used to be better...

(Do I need to say that I agree with Quentin?)

        Johnny

Quentin Garnier wrote:
On Sun, Mar 07, 2010 at 06:43:49PM +0900, Masao Uebayashi wrote:
[...]
a) Device enumeration is unstable / unpredictable

dk(4) is a pseudo device, and its instances are numbered in the order it's
created.  This is fine when you manually / explicitly add wedges(4) by using
"dkctl addwedge".  This is not fine, if I have a gpt(4) disk label which has
ordered partitions.  I expect disks to be created in the order I write in
the gpt(4) disk label.  It's annoying the numbering changes when I add a new
disk.  Same for raidframe(4).

You're barking up the wrong tree.  What's annoying is not that the
numbering changes.  It is that the numbering is relevant to the use of
the device.  I expect dk(4) devices to be given names (be it real names
or GUIDs), and I expect to be able to use that whenever I currently have
to use a string of the form "dkN".

[...]
- Intuitivity

Behavior should be simple enough for users to guess without looking into code.

What kind of user do you talk about here?  If it's the end user, then
this is wrong.  All that you mention should be irrelevant to them.

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

- Simplicity, clarity, consistency

Common code is concentrated in single place.  Each driver implements only its
hardware accessors.  No scattered ioctl handlings.

You forgot world peace.

1) Introducing devfs

devfs is a pseudo filesystem which shows device topology in a mount point.

This is not what devfs is.

There's (unfinished) branch mjf-devfs.  devfs helps to identify devices
uniquely.  wd0 on my DELL OptiPlex 745 looks like:

        /dev/mainbus/pci0/ppb0/piixide0/atabus0/wd0

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.

Beside, imagine you move said hard drive from one port to the other (or
on to another, say, faster controller);  the ultimate idea of devfs is
that the device node for the hard drive doesn't change.

Not that full, explicit device paths aren't something useful to expose
one way or another to the userland.  It's just not what devfs is about,
so you should revise your vocabulary here.

2) Natural device numbering

Device number in devfs is enumerated locally in the attachment.  Numbers are
*naturally* assigned; should match physical bus/slot numbers so that users
can make sure which is which.  This is important especially for block devices.
Think when you plug a USB floppy and newfs it.

Again, users shouldn't have to care about device numbering.  With your
idea of numbering, the way to access a device should change depending on
which USB port I put my usb key drive in?  I fail to see how this is
better than what we have now.

[...]
3) "Functional" device instances abstraction
[...]
This also helps users to understand how its internal works.  Users basically
accesses the device via audio(4) interface.  audio(4) is responsible to
interact with real hardware drivers.  Both control and data are transfered
via audio(4).  It's also easily guessed if user forcibly control real device
(azalia(4)), audio(4) would be *surprised*, and some inconsistency will be
expected to happen.

wscons(4)/tty(4) could be abstracted like:

        /dev/mainbus0/.../pci0/vga0/display0/screen0/vt100emul0/termios0/tty0

This might look redundant, but each device instance's *responsibility* is
very clear.  tty(4) is *the* device you interact when you use it as a tty.
Pretty much straightforward.  When you send a tty ioctl, it goes to tty(4),
which may be delivered to upper layers.  To add a new screen, it's obvious
that the device we should ask to is display(4).  We can guess how control/data
is delivered.  We can also guess forcibly deleting a screen causes its child
devices problems, because topology is visible.

wscons(4) without emulation would look like:

        /dev/mainbus0/.../pci0/vga0/display0/screen1

We don't need a detailed manual page how screen0 / screen1 are interfaced,
because it's obvious.

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.

[...]
P.S.  I've read 0 line of devfs code yet.

Really?

It seems to me that you are really confused, about a number of things.
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.

And device paths are not devfs, okay?



--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


Home | Main Index | Thread Index | Old Index