Re: More on bigger kdev_t

Andries.Brouwer@cwi.nl
Sat, 9 Oct 1999 20:18:46 +0200 (MET DST)


> What are all the fields for?

Well, there was discussion on linux-kernel, I am too
lazy to repeat everything, just some references:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/9910.0/0926.html

[this is the project to do]

http://www.uwsg.indiana.edu/hypermail/linux/kernel/9910.0/0944.html

[this is Andrea, quoting a list of fields from the previous ref]

> What else should be added?

The structure we aim for is to have two structs,
let us say majorstruct and minorstruct.
The majorstruct has fields like blocksize, readahead, etc. etc,
all what is found in fixed arrays these days. It also has a
field major, the major device number.
The minorstruct has fields like blocksize etc (to accommodate
those cases where we have a two-dimensional array today, indexed
by both major and minor), has a pointer to the majorstruct it
belongs to, and also has a field minor, the minor device number.
A kdev_t is a pointer to a minorstruct.
Thus, we get the defines
#define MINOR(dev) dev->minor
#define MAJOR(dev) dev->major->major
By the way, the majorstruct also has a field pointing to a function
with a kdev_t argument that returns the name of the device,
to be used in error messages.
Majorstructs will usually be allocated statically in the corresponding
driver. Minorstructs may be allocated dynamically.
These days I find that between 2000 and 3000 of them get
allocated on my machines. This is a largish number, so
minorstructs should be small.

Andries

-
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/