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

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