<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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/