On Sun, Mar 07, 2010 at 06:43:49PM +0900, Masao Uebayashi wrote:
[...]
quoted text
> a) Device enumeration is unstable / unpredictable
>=20
> 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 us=
ing
quoted text
> "dkctl addwedge".  This is not fine, if I have a gpt(4) disk label which =
has
quoted text
> 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
quoted text
> 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".

[...]
quoted text
> - Intuitivity
>=20
> 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.

quoted text
> - Predictability / stability
>=20
> 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
quoted text
> 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.

quoted text
> - Simplicity, clarity, consistency
>=20
> Common code is concentrated in single place.  Each driver implements only=
 its
quoted text
> hardware accessors.  No scattered ioctl handlings.

You forgot world peace.

quoted text
> 1) Introducing devfs
>=20
> devfs is a pseudo filesystem which shows device topology in a mount point.

This is not what devfs is.

quoted text
> There's (unfinished) branch mjf-devfs.  devfs helps to identify devices
> uniquely.  wd0 on my DELL OptiPlex 745 looks like:
>=20
> 	/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.

quoted text
> 2) Natural device numbering
>=20
> Device number in devfs is enumerated locally in the attachment.  Numbers =
are
quoted text
> *naturally* assigned; should match physical bus/slot numbers so that users
> can make sure which is which.  This is important especially for block dev=
ices.
quoted text
> 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.

[...]
quoted text
> 3) "Functional" device instances abstraction
[...]
quoted text
> This also helps users to understand how its internal works.  Users basica=
lly
quoted text
> 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 dev=
ice
quoted text
> (azalia(4)), audio(4) would be *surprised*, and some inconsistency will be
> expected to happen.
>=20
> wscons(4)/tty(4) could be abstracted like:
>=20
> 	/dev/mainbus0/.../pci0/vga0/display0/screen0/vt100emul0/termios0/tty0
>=20
> 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=
),
quoted text
> 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
quoted text
> is delivered.  We can also guess forcibly deleting a screen causes its ch=
ild
quoted text
> devices problems, because topology is visible.
>=20
> wscons(4) without emulation would look like:
>=20
> 	/dev/mainbus0/.../pci0/vga0/display0/screen1
>=20
> 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.

[...]
quoted text
> 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?

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.