Messages in this thread | | | Date | Wed, 16 Jun 1999 22:58:00 +1000 | From | Richard Gooch <> | Subject | Re: UUIDs (and devfs and major/minor numbers) |
| |
Stephen Frost writes: > On Wed, 16 Jun 1999, Richard Gooch wrote: > > > > > > > You mean /dev/ide/bus#/cd/device# as compared to /dev/ide/cd/location# > > > > > > I assume? > > > > > > > > > > Perhaps even /dev/ide/bus0/master (but, as I said, that may be too > > > > > much purism - even Solaris doesn't quite go that far) > > > > > > > > But what advantages would be derived from this purism (in the default, > > > > kernel-supplied virtual FS)? If there was some use to this structure, > > > > why not have devfsd create it from the existing structure that the > > > > devfs patch provides? > > > > > > The advantage would be that you're talking about a particular > > > device at a particular place. /dev/ide/cd/device1 doesn't tell you what > > > IDE bus you're talking to (At least, not obviously, perhaps the 1 is > > > signifigant). > > > > Currently, ide-cd will register /dev/ide/cd/c#b#t#u#. So it's a > > location-based name. So you know "where" the device is. If you prefer > > an order-of-detection-based name, you can look at /dev/hd? > > > > So you *can* talk about a particular device at a particular place with > > devfs. > > Yes, as I said, it's nit-picking. It's a matter of the > directory structure, device-type (/dev/ide/cd) vs. device-location > (/dev/ide#/master). Perhaps I'm missing the point on what Ted was > saying, but if changing that will move devfs closer to being in the > mainstream kernel, I'm all for it. :)
Tell me why the driver-supplied names should be anything other than what I've done already.
I see two questions:
1) whether device-location naming is warranted
2) what naming scheme drivers should provide.
For (1), you can get it by configuring devfsd, irrespective of (2). It's just a matter of configuration. For this case, (2) is just like using major and minor numbers. What the drivers provide is just a key.
For (2), the scheme I've implemented makes sense. It reflects the way the drivers are organised. Take SCSI as an example. You have a basic SCSI layer which scans for controllers and devices. This layer doesn't provide anything useful for user space. Then you have individual device-type drivers, which provide an interface to user space. Thus the grouping should be done by driver.
Let's say you had device-location naming instead. So you might have: /dev/scsi/c0/b0/t0/u0
Or at least, you'd think so. But this isn't right. Such a name has no meaning, because it doesn't say how to access the device (sd, sg, st, etc.). So really, you need to have: /dev/scsi/c0/b0/t0/u0/sd
But this is really ugly. In order to construct a human-friendly /dev, you have to go through a fair bit of work. And it is a far less flexible scheme than what the devfs patch does currently. It would be hard or impossible to do nice things like the CD-ROM scanning I've discussed.
So then you come to the question of why impose a structure that fits one particular view of how device names should be organised (for internal purposes), which can't be used as-is? Why not have an equally logical structure that is actually useful to real people?
So here we are, arguing about names, because suddenly Ted admitted that a virtual FS might be good. But then he says he doesn't like the names. Before that he was denying to the hilt that a virtual FS had any merit.
Complaining about names is no justification for keeping devfs out of the kernel, though, because: - you can use devfsd to build your favourite structure (allowing people to experiment) - the current structure is actually useful.
I've even sent Linus a patch that contains just the devfs infrastructure, but doesn't touch any drivers or config.in files, in the hope that the issues can be clearly separated. I'm tired of going through the following routine:
1) Me: I think devfs should go in the kernel, because ... 2) DO: DEVFS SUCKS! It's a BAAAAAAD idea 3) Me: No, it allows you to do ... 4) DO: YOU CAN DO IT ALL IN USER SPACE 5) Me: Some things, yes, but not everything and not efficiently 6) DO: Put a small hack into the kernel and the rest in user space 7) Me: But then ... is hard/impossible 8) DO: Make the kernel hack bigger 9) Me: Now you've got something like devfs 10) DO: But you've got names and that's "policy", and I don't like yours 11) Me: So use devfsd and change them 12) DO: goto (4).
"DO" is Devfs Opponent.
Sigh. Over the past year and a half, I've noticed a distinct pattern. It seems impossible to make any progress in this argument, because so often, when I press on one point, demonstrating why devfs wins out, the argument is shifted to another point. After a while, the first point is suddenly popped up.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |