lkml.org 
[lkml]   [1999]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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