>> Hi Linus
>>
>> I have just been reading the 2.1.71 and I must admit that I am
>> fairly annoyed with the mess of the new byteorder code, to put it
>> in a mild way.
Jakub> I don't see why do you consider it to be a "mess". I see such
Jakub> a patch as a great simplification and unification, puts the
Jakub> common stuff from all the byteorder.h headers to common part,
Jakub> keeping there only stuff which they differ in. I must admit I
Jakub> haven't tested it yet (need to finish RTSIG first), but haven't
Jakub> seen there any problems.
Well they are huge and put asm specific stuff in the generic
directory. The vax file simply shows that architectural stuff is in a
place where it IMHO does not belong.
>> First of all it I think it is a total mess and secondly I am very
>> annoyed that it removes our nice architecture optimizations. Could
>> you please reverse it until it has been done the right way.
Jakub> Which optimizations are removed? As far as I see the patch, all
Jakub> optimizations are kept, but the "mess" is gone.
No, the old solution was much nicer, this is a mess. I don't like the
idea of going through this master interface in include/linux, the
respective architecture developers knows how to do things for their
architecture not the other way round. The new files are _huge_ and
lists tons of various defines without any sort of explanation, its a
nightmare to read.
And for missing uptimisations then I miss some stuff from
include/asm-m68k/ related to the use of constant values.
Jakub> Oh yes, this is just one thing which I think could be changed,
Jakub> names like linux/byteorder_g.h, linux/byteorder_be.h,
Jakub> linux/byteorder_le.h ... would do it as well, or even be.h,
Jakub> le.h, maybe not linux/byteorder.h for generic as that would
Jakub> confuse the users, but that's not a thing why to reject such a
Jakub> patch.
byteorder_[lb]e.h would be fine, but seriously by keeping the stuff in
place where it belongs, we would not need these files at all.
>> Second, instead of keeping these gigantic files of swap functions
>> and defines and then let the architetures overwrite these it would
>> be much cleaner to provide a library of generic functions (in fact
>> this would be very small, only 3 in fact, 16, 32 and 64 bit swaps)
>> and then let asm/byteorder use these if there are no optimized
>> ones.
Jakub> Putting these into a library might be "clean", but would slow
Jakub> all the platforms down in an inacceptable way. Most of these
Jakub> are single-liners and all of them are inlined, what makes a big
Jakub> difference.
I did not express myself clearly enough here, by library I do not mean
something compiled statically in lib/ or something but rather
a set of macros that one can choose to use from
include/asm/byteorder.h through defines, ie.
#define cpu_to_foo() __generic_swab_foo()
Jes