Messages in this thread |  | | | Date | Tue, 25 Nov 1997 16:47:48 -0800 (PST) | | From | Linus Torvalds <> | | Subject | Re: TTY changes to 2.1.65 |
| |
On Tue, 25 Nov 1997, Theodore Y. Ts'o wrote: > > Another thing I would like to see in the generic code is an interface > to register serial drivers instead of the current approach where every > serial driver is assigned its own major. > > I see no reason for wasting all these majors on this and IMHO it is a > lot better to use dynamic allocation of serial devices, thus if one > replaces a serial board with a different brand it is not necessary to > go and change the entire software setup. > > It's something to think about, but doing this in a way that doesn't > break compatibility with either (a) existing systems' /dev directories > and (b) all of the existing tty device drivers will be a wee bit > challenging. It'll probably be a while before I get to this one, > actually.
I don't actually think we should do this the way Jes implies.
I _do_ think that we should have an added level of indirection between the devices and the device numbers, though. Every time larger device numbers come up, the added indirection also tends to come up.
In short, I think it makes sense to have a better mapping from device numbers to actual devices, and I _don't_ think that this mapping should be done by the device layer, it should be done at a higher level. A better mapping gives us:
- binary compatibility. Imagine a platform where you want to support different device numbering schemes by different systems. You may want to make the device numbers more "virtual", in that they might depend on the type of process you're running.
- sharing majors between devices. Right now this is rather painful, and we have this "misc" device for a specific subset of this (mice and other random devices that tend to need only one minor number). But if we again had this mapping done in a more generic way, we could for example have two different SCSI device drivers that wouldn't have any common ground, and instead of having the SCSI driver figure out what the major means, we'd have the device mapper just do it at a higher level so that the devices really could be totally independent.
- IO request queues. Right now the IO requests are done according to major number, but if we had a better internal representation we could make the IO request queues be per-device (or per-driver, depending on how the driver wants them). Again, the reason why we queue them per major is not because we want to, but because we want to do the queuing at a higher level that doesn't know about driver internals. If we had a "mapper" level for device numbers, we could do much better queueing.
- performance. 16-bit device numbers are actually _bad_ for performance, because on many architectures (including intel, although less so than with some others), accessing and comparing 16-bit entities is slower than using pointers or other more "native" data structures. Using another format internally may be advantageous.
- backwards compatibility - when device numbers change, the drivers themselves wouldn't need to worry, only the mapper would be implicated (this is kind of the same issue as binary compatibility).
and
- the above case: we could much more easily pack different drivers to use the same "major" because the drivers themselves wouldn't even know.
In short, I'd actually like an approach where kernel internals use a opaque "device ID" - that doesn't have a minor or a major associated with it at all.
As mentioned, this has been talked about before, and I think Andries Brouwer actually had patches to do some of it (the "device ID" being a pointer to a device block).
Linus
|  |