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/