Messages in this thread | | | Date | Mon, 6 Dec 1999 17:41:36 +0100 (MET) | From | Andries.Brouwer@cwi ... | Subject | Re: PATCH for 2.3.29: block device setup cleanup. |
| |
I wrote .. > then you can have today > > #define READ_AHEAD(x) read_ahead[MAJOR(x)] > > and tomorrow > > #define READ_AHEAD(x) (x)->majordev->read_ahead
and also
> And Linus might accept such a change even during code-freeze > times since the generated code remains the same.
Linus answers:
Actually, I detest macros used to hide these kinds of details.
I'd much rather see a structure pointer implementation immediately than any half-way point that uses macros as a way to change things later.
And, Linus, of course my taste is not different from yours. On the other hand, you seem to be asking for all-or-nothing, and so far it has mainly been nothing. Now it is Marcin's turn, and perhaps he has so much time and energy that he can complete this in one go. But the kernel is in a perpetual state of flux, and this is a patch that touches a very large number of kernel files - it is not easy to do it all at once. But it is quite possible to go in stages, so that the final changeover is just changing #if 0 into #if 1, and people who want can test the intermediate stages.
I did this a number of times, and try to share experience with Marcin. For example, the NFS code causes problems. Now the macro approach enables one to use structure pointers when NFS is not compiled in and old-fashioned code when it is. (I fixed NFS once and sent you the patch, but I don't think you ever reacted.) The macro approach also allows one to experiment with several possible implementations and see whether any difference in timing is noticeable.
Now I had as goal on the one hand creation of device structs, on the other hand allowing large minors, a bonus that comes for free. You seem to want block device structs only. That makes things a bit easier but of course reaches only one of the two goals.
Marcin, it seems you do not understand me at all.
You write:
5. It's not this level of the interface which is going to change. Wherever possible I'm going to pass the pointer to the blk_dev_struct instead of kdev_t
But kdev_t *is* the pointer to the blk_dev_struct.
You continue describing what a good idea this is. Yes, that is why I introduced kdev_t.
(It took quite time for me before I guessed correctly the semantics of blk_size and blksize_size, in esp. the second is a wonderfull name.)
Yes. Of course these must be changed into size and blocksize, respectively.
You include a patch - will look at it later.
Andries
- 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/
| |