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?