Hi,
I have a suggestion for 2.5 (and an almost working patch): isn't it
about time to introduce a bdev_t structure that contains all the
information that is scattered over lots of places?
That would be:
struct block_device
struct gendisk
struct sec_size
struct blk_dev_struct
read_ahead
blk_dev_struct
blk_size
blksize_size
hardsect_size
max_readahead
max_sectors
max_segments
ro_bits
And probably more redundant information in the devfs, but I disabled
that, so it's not working yet.
Anyway, my main question is there a interest in such a cleanup? It would
help save memory wasted by all the arrays, it would simplify lots of
functions/operations that operate on these arrays to find some
information and it would remove several limitations we still have.
I hope there is enough interest in this, so it could be included in
early 2.5, but I'd rather liked to know now if there is a chance for
that to happen, otherwise I can stop wasting my time on this.
IMO it's badly needed, I hoped that this would already happened with
devfs, but as far as I see it increased the mess only. So here some
ideas, how the new interface could look like (I'm working forward that,
but there I'm not there yet):
- all of the kdev_t arguments for block devices are changed into bdev_t
and we keep a hash to get a bdev_t from a dev_t.
- block devices should need to know as little as possible about
partitions or the devfs, the current major/minor mess is translated to
three indices: driver, disk and partition index, what can be completly
dynamic, so you have a register_blkdev(), register_disk() and
register_partition(), that build up a tree structure, devices like the
loop or ram disk devices can be allocated dynamically or can have
partitions (no more wasted space by arrays).
- the block size argument to bread/getblk is IMO redundant. (BTW this
makes the partition scanners simpler, it can use set_blocksize and can
simply work with a block index, also range check for getblk gets easier
as all information is easily to lookup.)
That's only a rough list and I can explain them in more detail, if there
is enough interest, but for now I'm more interested if there is any
interest at all.
bye, Roman
