Subject: Re: Another changer, another changer problem
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: David Holland <email@example.com>
Date: 10/19/1998 18:46:34
> Let's assume that the question of how to handle devfs leaves is
> settled: either make them symlinks to elsewhere or back their
> permissions with a file or use an owner-and-mode translation layer or
> Then, how are partitions handled? If we want, say, /dev/usr to be a
> link into devfs, then we may have soemthing like
> /dev/usr -> /devfs/..../:scsibus0/targ=0,lun=0:sd0/
> ...and what comes after that last slash?
> If devfs is to be device-independent (which so far it seems it is; the
> discussion seems to be talking about a devfs that is little more than a
> filesystem presentation of the autoconfig device tree), where to 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.
> The only way I see for this to work is for sd0 to be the leaf and to go
> with a more generalized partitioning scheme, perhaps akin to the
> labelfs that was bandied about.
This is another possibility.
> That labelfs itself brings up more problems. Suppose, for the sake of
> argument, that we do
> mount -t labelfs /dev/sd0 /dev/psd0
> and then want to use /dev/psd0/a, /dev/psd0/b, etc.
> What sort of filesystem entities are /dev/psd0/a, /dev/psd0/b, etc?
> The only thing they can be, really, is device special files. Then the
> question is, what major/minor do they have? And how does this interact
> with modifying disklabels on a running system?
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.
You could also choose a major number and then allocate minor numbers
on the fly; the allocation wouldn't have to necessarily make any sense
or even be repeatable/persistent because the labelfs would make sure
the right names named the right things.
wait, that's exactly what you said.
> 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.
> > 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.
Depending on what you want to do with it, of course.
- David A. Holland | (please continue to send non-list mail to
firstname.lastname@example.org | email@example.com. yes, I moved.)