Linux-kernel mailing list archive 2000-40,: Re: Meaning of blk_size

# Re: Meaning of blk_size

Andries Brouwer (aeb@veritas.com)
Mon, 2 Oct 2000 20:28:20 +0200

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Rik van Riel: "Re: TODO list for new VM (oct 2000)"
- Previous message: really mason@soo.com: "Re: Oops at bootup with 2.4.0-test9-pre8"

On Mon, Oct 02, 2000 at 07:11:52PM +0200, Daniel Phillips wrote:

> One more question that has probably been asked a lot: why are the
> various fields of a device splatted across half a dozen tables instead
> of being collected together in a struct and accessed through one table?

Yes, this has been asked a lot.

I did this a few times. Half of the work was the introduction
of the kdev_t opaque type - the patch was around 1.3.20.
I am very glad this happened - it was a lot of work, determining
for all integers in the kernel whether they held a device value
or not. Today the kernel is seven times as large and such a change
would be next to impossible.

The other half increased in magnitude in the past five years.
It is what you suggest: have a kdev_t that is a pointer to a
struct that contains the fields that today live in these arrays.

device size is a 64-bit bytecount, so no granularity problems.

These days I have as background activity the construction
of the corresponding patch for 2.4. Maybe we can start 2.5
without these arrays and with large device numbers.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Rik van Riel: "Re: TODO list for new VM (oct 2000)"
- Previous message: really mason@soo.com: "Re: Oops at bootup with 2.4.0-test9-pre8"