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

    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:

    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:

    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

    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 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 ...
    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.



    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.025 / U:79.740 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site