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.
Andries.Brouwer@cwi.nl wrote:
>
> 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.

I will not reply on this by now, becouse I need some time to think it over.

> 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.

No not quite. I think once again that in fact the only missunderstanding between
us is on the e-mail communication level. Please just have a close enough
look at the patch itself. I have put some comments in here and there
which should explain things a bit more. Thereafter I think you will see
that mainly the only difference in our gals in whatever we call it
typedef struct __kdev_t kdev_t;
or directly typedef struct blk_dev_struct;

In esp. At some point in time the blk_dev array will be changed to an entierly
dynamic array of handler struct for devices not just major numbers.
Once again i think the only difference between my approach and yours is that
I'm aimin at the whole issure from the bottom (read device handling part)
instead of starting by the top (kdev_t type and passing semantics).
This is becouse I think that the lower level stuff is just a prerequsite
for the second. Surely at the finish line I see too that kdev_t (or whatever
name we end up....) will be vanishing.

> Marcin, it seems you do not understand me at all.

Belevme I'm better at understanding english then writing it myself.
However alternatively my german is native grade and since you are from
the NL chances are good that we could settle on it better in priv OK?

Glaub mir bitte, mein passives english ist deutlich besser als das was ich
selbst schreibe, so dass unsere verstaendigungsprobleme wohl groesstenteils
darauf zurueck zu fuehren sein duerften. So ist zumindest mein eindruck.
(OK ein legastheniker bin ich in jeder sprache so oder so ;-).

> 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.

Yeep I hope it will clarify some bits. (Since code doesn't bear all the
problems of interhuman communication semantics ;-).

--Marcin
>
> 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.047 / U:48.648 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site