I don't think quite so if you think bit further...
> - read_ahead[MAJOR(dev)] = arg;
> + blk_dev[MAJOR(dev)].read_ahead = arg;
>
> You make ugly code even uglier. In my source that line reads
>
> dev->majordev->read_ahead = arg;
>
> You still do not want to view a kdev_t as a pointer
> to a struct with information?
No no I think you have quite a bit misunderstood me.
The code you see now as ugly is intermediary. (However I still think
that it's more clean then prviously.) The intention is to gather
all the pieces needed to handle the devices internally step by step
together. And then it shouldn't matter anylonger whatever you call it
typedef struct __kdev_t *kdev_t;
or typdef struct __blk_dev_struct *kdev_t;
I intend to replace all the foo(kdev_t im_an_index) by a pointer
to such a common struct of course...
But I would much preferr to do it along some kind of incremental
"upgrade path"
thus making sure that as few thing get broken or even better many things
get
clarifyed/corrected that where broken or abused before.
Please see my comments about the max_* fields and such.
So I think our goals are basically very much the same but however I
don't
intend to magically supply a megaton patch. I would rather much like to
do it somehow in a more visibly (controlled) incremental way by not
changing way too many things at one step. (Think of at as a
sequence of waves in comparision to a tsunami ;-).
I hope you understand my intentions a bit better now?
--Marcin
-
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/