[lkml]   [1999]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [linux-usb] Re: USB device allocation
    > -----Original Message-----
    > From: Richard B. Johnson []

    <some snippage>
    > To give a simple example, given:
    > LargeFileNameDirectory/LFN-Subdirectory/MyFile.txt
    > ... requires 3 directory lookups to obtain a number. After which,
    > the file is accessed as a number. It is read/written/extended/truncated,
    > /seeked, etc, without ever having to parse strings again.
    > The same is true for 'special files'. These require a lookup first
    > to associate a major/minor number (instead of an inode). Then the
    > human readable name string is never accessed again. To do it any other
    > way would be to return to the days before even CP/M.
    > Historical buffs may remember that the file-system on the famous
    > "green-machine" (MDS-200), circa 1967, consisted of 'directory' entries
    > that contained only numbers. A directory program translated these numbers
    > into strings in a "container file". (No M$ didn't invent the container
    > file). Even then, it was understood that strings didn't belong within
    > an operating system.
    > So, we are not "fumbling around" with the major/minor concept. It
    > is an excellent, efficient way of handling devices. However, soon
    > it will have to be extended because we need more numbers.

    I think I am beginning to understand (sorry, I am definately _not_ an OS
    expert :)). But after a file is open'ed, does it even matter how the user
    got there? I am under the impression that an open'ed character device is
    just a pipe to the respective hardware driver. After you have a file
    descriptor, it doesn't matter if there was a major/minor number associated
    at all.

    But what a major/minor does buy is an easy transition from a file to the
    respective subsystem. 192/12 might mean 'the usb driver, 12th device'. After
    everything is in place, it really doesn't matter that we used the
    major/minor pair at all to open things up.

    The problems come when devices with the same function are plugged in on
    different ports. People tend to think in terms of purpose, not 'bus' or
    'protocol'. It makes no sense to some people that a printer connected via
    the parallel port has a different interface than a printer connected to usb.

    The second problem comes when you start to face the fact that the devices
    are not constant. This is a big problem for USB and all the new plug-and-go
    equipment. If you plug in two devices and then unplug them both, then replug
    them in opposite order, they switch. This does not have to be a manual
    thing, for instance the power goes out here in Florida frequently, and my
    powered USB hub goes on and off constantly. Imagine if that happened right
    as I was getting ready to format my USB scsi drive.. and instead formatted
    my 12 Gb firewire hard disk (which had all my work for the last six months)

    The third problem is slightly easier- 256 devices per major is not enough.
    Even if you had only a few USB devices, they can technically be multiple
    interface devices, and each interface gets parsed to a separate device as
    far as the system is concerned. For instance, a USB connection to a stereo
    would have interfaces to adjust all the knobs, read all the buttons, and
    probably would allow you to use it as sound input/output to the computer.
    This could potentially be 5-10 devices. Allow for separate files to perform
    usb (bus specific) functions on these devices as well. You soon see that we
    could not be limited to a single major with only 256 minors.

    So while using numbers in the lookup mechanism is very efficient, having the
    numbers statically assigned really doesn't work as well as we need. Ideally,
    we would be able to have 65k devices in our computers with the unique
    numbers, I really hope I never see a computer that has to handle more than
    that :) But with the current static assignment, we have to place all sorts
    of arbitrary limitations to get things to work.

    So yes, I see that lookup speed is important (although not as important as
    communication speed, and communication channels are not even involved here.)
    But the problem is that with plug and play devices, you really cannot have
    static numerical assignments -and that is what /dev gives us right now. The
    only really workable solution right now would probably be to have two majors
    for usb, and just number everything usb0, usb1, ... usb511. Then have a
    userspace daemon that can create intelligent links from those (i.e.
    recommend strongly that these are never, EVER used directly, because disk
    corruption/100 pages of garbage off the printer/blown speakers will result).

    Otherwise we have to partition off serial devices, mice, keyboards,
    joysticks, printers, scanners, cameras, speakers, etc. all into separate
    categories, giving an arbitrary limitation on the number of devices allowed
    for each. And, we would still have the problem that devices will move (not
    could, will).

    This is why a dynamic (non physical disk based) devfs appeals to a lot of
    people working on this. You could pretty much just arbitrarily set up the
    routes per device. major 192 is now the scsi card, there is a scanner, so we
    name it scanner0 and give it a major 192 minor 7. Or possibly even a
    different mechanism, if that will cause the lookup to be faster (although
    again, the lookup isn't really a bottleneck.) This can't be done without a
    userspace daemon, which would become pretty much required. And it is a big
    change from the current system. And I know I am not covering all the issues,
    because like I said, I am not an OS expert (not enough years of experience,
    yet). But I really hope that this explains the current problem.

    It is not just a USB problem, things like hot-pluggable PCI exist already.
    Firewire and USB are out there, and more things are coming. It will not be
    long until something like firewire or USB2 is used internally for things
    like hard disks (USB1 is not fast enough for this). So the problem will not
    go away, and although expanding the major/minor to be two 16 bit fields
    would solve the 'running out of minors' problem, it would not solve the fact
    that the device order is not constant, even in normal use, and that this
    problem cannot be solved with in-driver heuristics (or at least, Linus says
    he will not accept patches with such heuristics in them).

    -David Waite

    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:54    [W:0.039 / U:113.216 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site