[lkml]   [1999]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: UUIDs (and devfs and major/minor numbers)
Theodore Y. Ts'o writes:
> Look to devfs as a way of cleaning up procfs instead. Move all the
> non-process stuff into devfs. That way we can get back to a procfs the
> way it was intended.
> Well, no, that doesn't work, since there plenty of non-process stuff
> which doesn't fit into a devfs mounted in /dev.

Such as?

> Now, if you were to make an argument for a /kern that had the
> non-related process stuff, and perhaps one of the things in /kern
> was something like was is in Solaris's /devices directory, that
> might be interesting. What Solaris has in /devices are names which
> are designed to be unique and explicit about what they are attached
> to. For example, we might have a device name vaguely like:
> /kernel/devices/pci/adaptec2980_0/id0/lun0/part1
> ...and then having a user-mode daemon make symlinks from /dev/sda1,
> or /dev/disks/<fslabel>, or /dev/scsi/disks/*, or whatever new
> experimental naming scheme that people want to experiment with.
> That's definitely policy that shouldn't be enforced by the kernel,
> so we would have a user-mode daemon that can consult a database (ala
> lspci, etc.) which can be changed when people want to experiment
> with different structures and hierarchies in /dev. This may or may
> not be the best approach, but I believe it's better than the current
> devfs approach.

Explain to me how this is different from mounting devfs onto /kernel
and using devfsd to populate a disc-based /dev.

> The bottom line for me is that kernel already has a very well
> developed backing store of files in /dev, and that's an ext2 or a
> minix filesystem. If you use that, then you don't need the tar file
> kludge at shutdown to preserve permissions.

I've addressed this point in the past. There are two solutions I'm
considering for this:
- make devfsd to the saving/restoring
- have devfs poke through to the underlying FS.

But this is a straw-man argument, because it ignores the persistence
problem with a dynamic disc-based /dev which is managed with a user
space daemon. This is a problem that's been overlooked.

Consider what happens if your daemon creates and deletes device
entries based on information from the kernel as to what devices are
installed (and drivers loaded). When a new device is plugged in, *what
permissions should be given*? OK, say you get some default. So the
sysadmin does chmod(1) to change this.

What happens if a device is removed? The daemon deletes the device
entry. Then the device is plugged back in again. *What permissions
will be given*?

So, your argument against devfs is really an argument against a
dynamic /dev. But you don't really want to argue against a dynamic
/dev, do you? You just want to argue about devfs.

> It's also clear that the decision of what the names of files in /dev
> really should be done in user-space,

No, that's your opinion.

> and should possibly consult a configuration file.

So mount devfs onto /devices and configure devfsd to
populate/depopulate /dev.

> There is clearly some functionality in devfs which is useful; but
> something which overmounts /dev really is the wrong long-term
> approach IMO.

The sysadmin gets to chose where devfs is mounted. It doesn't *have*
to overmount /dev.

Again I'll ask the question I've already asked a number of times. How
would you cleanly support a construct like this:
opendir ("/dev/ide/cd");

and be assured that your loop sees only the IDE CD-ROMs plugged into
your system, and also ensures the the right driver is loaded?
This requires a virtual /dev, not just a dynamic /dev.

Sure, you can get around it by having /dev/ide/cd a symlink to
/devices/ide/cd, but then you're going to have to populate /dev with a
pile of symlinks for hardware or drivers you might not even have.

However, if you want to set up your system with a symlink farm for
devices that you don't have, that's your choice. Mount devfs onto
/devices and configure devfsd appropriately.

> In the end, even if we agree that /proc should be cleaned up, that
> doesn't mean we should put other code which makes similar design
> choices/mistakes into the kernel.

Except that devfs isn't a mistake. It's the Right Thing[tm].



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.115 / U:33.380 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site