lkml.org 
[lkml]   [1997]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans