Messages in this thread |  | | Date | Mon, 2 Oct 2000 20:28:20 +0200 | From | Andries Brouwer <> | Subject | Re: Meaning of blk_size |
| |
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/
|  |