[lkml]   [2001]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: LANANA: To Pending Device Number Registrants
    [ I normally just lurk and read the archives,'s where I get into
    trouble! ]

    It seems to me that there are several issues that have come up in this thread,
    but here are my thoughts on some of them:

    * Identifying hardware:
    Since we don't want to use topology as the primary method of
    identifying a device, perhaps it could be the secondary method. If a device
    id consisted of several parts, userspace could make an educated guess about
    which devices correspond to which names, across reboots. Consider an ID
    consisting of:
    * vendor
    * model
    * serial number
    * content-cookie
    * topology-cookie
    The two cookie values are opaque, but reproducable. The content cookie might
    be an MD5 of the partition table of a disk, or its serial number, or
    something to that effect. The topology cookie would some topology
    parameters (such as mem address, irq, io ports, slot #, etc) which could be
    used to identify the device later. These are only used for identification,
    not for discovering topology.

    If all 5 fields match, then we know what it is. If only topology-cookie is
    different, then it just moved. If content-cookie is different then it might
    be a different device (There's a trickyness to partitioning, I suppose).

    I suppose these ID fields could also be used by a userspace tool to
    load/unload drivers as necessary.

    The id could also determine the device is only inaccessable (not removed)
    when it disappears. So, if disk5 disappeared on reboot, the next disk
    added would be given an ID at the end of the list, while disk5 would remain
    unused. Only on a 'cleanup' would disk5 become reassignable. This fixes
    issues like a device being unpowered on boot and a new one being powered up.

    * User-space device naming
    I think the diskN naming is nice. "randomly assigned" major ids won't be a
    problem, except on NFS mounted /dev directories. If the kernel maintained
    a filesystem (like devfs or proc) which always managed the "currently
    available" devices the only problem to solve would be dealing with software
    which opens the /dev node to get a driver loaded.

    It would be very cool if the dev filesystem could be exported to other linux
    boxes, so you could transparently have access to block devices (like nbd does
    now) and character devices (like the sound card)

    mount -t dev -o other_machine /dev/other_machine
    cat > /dev/other_machine/audio &

    * IOCTL
    Since ioctl() is commonly regarded as a kluge, is there any reason why it
    couldn't be replaced by the /dev/fb0/frame0 thing that was described earlier?
    The libc implementation of ioctl could convert the binary data back into
    text calls. Gross, but possible...though it would probably be better to just
    depreciate the ioctl mechanism. It could also package it for remote
    usage (see my pipe_dream above).

    If device info/controls are tied to subdirectory entries, it would be nice
    to be able to get a device's capabilities via existance checking...
    I.E. '-e /dev/disk0/eject' could check of the device is ejectable.

    Brian Wheeler
    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.028 / U:37.236 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site