>> If devfs is to be device-independent [...], where [do] disk
>> partitions fit into it?  The autoconfig code knows nothing about
>> them, and I am inclined to say it probably shouldn't.
> It could - go look at the partition table thread if you didn't see
> what I suggested there.

What I recall seeing there works well only when disklabels don't change
at run-time.  Imagine ejecting a zip disk with am MBR partition table
on it and popping in one with a NetBSD label - you have to detach the
"fdisk* at sd?" attachments corresponding to it and create "dk* at sd?"
attachments for the new disk.

And what if there's a BSD label in one of those MBR partitions?  All of
a sudden the autoconf tree ends up having to support a whole lot of
stuff that it never has had to, and it has to have tie-ins to anything
that can modify a disk label, including the disk read/write routines.

Not that this is necessarily *wrong*.  But it "feels ugly" to me in a
way that the labelfs suggestion I gave doesn't.

>> mount -t labelfs /dev/sd0 /dev/psd0
>> What sort of filesystem entities are /dev/psd0/a, /dev/psd0/b, etc?
> In an ideal world they'd be device special files with no particularly
> special major/minor, that the devfs code or labelfs code would route
> off to the right place on its own.

But the labelfs code doesn't get control.  The vfs layer gets asked
what kind of object (say) /dev/psd0/a is, and it has to pass back
something.  If it passes back a device special file (and I can't think
of anything else it could usefully pass back), then I *think* it is out
of the loop thereafter; it's the driver for the major number of the
device that gets the call if the thing is to be opened.

> You could also choose a major number and then allocate minor numbers
> on the fly; [...]
> wait, that's exactly what you said.

Right, I believe you understood exactly what I meant.

>> Given such a labelfs, then the partition trouble in devfs magically
>> evaporates, since all the device node will be is a single raw disk
>> device - the partition devices will arise from labelfs mounts.
> Or you could build some or all of the same functionality into devfs.

Well, sure, but then you can't partition your disks without using
devfs, and some people don't like devfs but do want partitions.

>>> 1. provide a userland interface for enumerating the active devices,
>>>    without groveling kvm or dmesg output, or ioctl'ing everything
>>>    in /dev to see what doesn't return ENXIO.
> This is what /proc/devices in Linux does (in a limited fashion) and
> that may be a better way to get at this kind of information.

I don't use Linux and AFAIK have no docs on what /proc/devices is.  Can
you describe it?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B