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? -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "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.
Attachment:
pgpIinHMDYWM0.pgp
Description: PGP signature