[lkml]   [2001]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: LANANA: To Pending Device Number Registrants
    From wrote:
    [lots of sensible comments to get this discussion "on track"]

    > So we have: user space has file names and uses open() or mount().
    > Kernel space has device paths.
    > In principle the kernel could just number the devices it sees 1,2,...
    > and export information about them, so that user space can choose
    > the right number.
    > The part about exporting information is good. User space needs to
    > be able to ask if a certain beast is a CD reader, and if so what
    > manufacturer and model.
    > But the part about numbering 1,2,... may not be good enough, e.g.
    > because it does not survive reboots. If we remain Unix-like and use
    > device nodes in user space to pair a file name with a number, then
    > it would be very nice if the number encoded the device path uniquely.
    > Many programs expect this.
    > It cannot be done in all cases, but a good approximation is obtained
    > if the number is a hash of the device path. In so far the hash is
    > collision free we obtain numbers that stay unique over a reboot.

    I think here we might learn from the comments that people made
    about how AIX and OSF/1/Tru64 have been doing this.

    You want the relation between a given /dev/xyz node and the
    corresponding device in the kernel to be relatively stable from
    the perspective of the user, so you can use it to implement device
    naming and access policies. What "stable" means technically is a
    matter of policy, since it depends very much on the perspective
    of the user.

    You also want the relation between a given /dev/xyz node and the
    major/minor number of the related device to be "fixed", so you
    don't need to recreate all device nodes on every boot.

    The issue is then how to establish the relation between major/minor
    numbers and (potentially very dynamic) kernel-internal device
    entities, in such a way that the type of stability desired by
    the user is provided.

    As people noted, the mechanism used by AIX and Tru64 is essentially
    to have this relationship established by a user-level tool using
    a configuration file with policy information, and a status file
    to maintain state information across reboots.
    This tool can implement any policy it likes, which means we can
    avoid all the policy discusions where the kernel is concerned,
    and can instead focus on methods.

    For the people who want things to be backward compatible, it
    would be sufficient to implement a default tool that will
    set all the major/minor numbers exactly like they are now,
    so all existing device nodes will keep working as they did.

    In order to support hot plugging of devices, I suppose this
    tool should either run as a daemon, or set itself up to be
    called by the kernel whenever something happens. (I think
    I would prefer the daemon...) Sort of like /sbin/hotplug.

    The next issue to discuss is then how to shape the mechanism by
    which the device manager tool and the kernel exchange information
    on what devices are out there, and what major/minor numbers each
    should be assigned.
    The sort of information that a device manager might want to
    use, depending on how it is implemented and configured, would
    include such things as: device driver id, I/O bus, I/O port,
    IRQ nr, SCSI card/bus/id/lun, partition id, serial number,
    device model/type, filesystem label, filesystem UUID, phase of
    the moon, etc, etc.
    Basically, anything that a driver or related subsystem can come
    up with that might help identify a device or resource in any
    particular situation, depending on user preferences.
    I think this may fit somewhere in /proc/sys/dev or thereabout.

    The big advantage of this approach is basically that we can
    continue to use the good old device nodes in the filesystem
    as we have done for the last 30 years, with all the advantages,
    but without the major/minor number allocation troubles.

    Hmm, this all sounds too simple.
    I must be talking nonsense. Please wake me up. ;-)

    Willem Konynenberg <>
    I am not able rightly to apprehend the kind of confusion of ideas
    that could provoke such a question -- Charles Babbage
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:53    [W:0.038 / U:0.260 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site