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

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.118 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site