SUMMARY:
The only thing wrong with the byteorder patch is long filenames;
I chose to make them explicit and long because only Linus
is entitled to choose definite filename.
I suggest include/linux/byteorder/little_endian.h and such.
*I'm willing to make the changes and send them to Linus*...
LONG ANSWER:
> 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.
>
I'm sorry that you don't like the byteorder code.
I've received quite positive feedback, actually.
> 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.
>
The byteorder patch doesn't remove *any* single optimization!
On the contrary, it uniformly brings all the possible generic optimizations
from all the possible architectures to every other, while
preserving architecture-dependent optimizations (and they only)
in architecture-dependent files.
If you see no optimization in an architecture's file,
then it means there was no arch-dep optimization in 2.1.70 either.
I invite you to check this with `gcc -S -fverbose-asm -O2 foo.c -o foo.s`
with foo.c using a few byteorder functions (I can send you my own test
program, if you want).
Plus I've added 64-bit byteswapping *required by UFS* (and future ext3?),
uniformly for all architectures, as well as (partial) vaxendian support
(though I haven't received feedback from vaxlinux people; they look asleep).
> Instead of putting in gigantic files
Please note that despite new features (64bit, vaxendian, features made
available in userspace w/o posix namespace pollution),
and lots of comments, and additional stubs, my patch *reduces*
overall kernel file size.
> with 22 byte long file-names, which
> will not work on good old Minix v1 filesystems - yes some people still
> use those for Linux - it would be better to keep the names below 14
> chars and there is absolutely no reason to use such long filenames.
>
Well, I admit *this* is the weak point, but only of superficial nature.
I hesitated before doing that. The other solution was to create a
subdirectory for byteorder files. I would have put them in asm-generic/
but asm-generic/ isn't generally accessible from user programs.
I didn't want to make cryptic filenames either (like byteorder_le.h,
bo_ve.h, bog.h), or lost in the mass (little_endian.h, byteorder.h, etc).
All in all, it's really up to Linus to decide the Right_File_Name(TM)
for the common files; I made the filename so he could understand what they
were, and modify the filenames accordingly.
> 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.
>
Problems: should generic files be included before or after arch-dep #defines?
If the answer is after, they my patch is just perfect.
If it's before, then arch-dep #defines and optimization can't be understood
by generic patches, and every architecture would have to duplicate huge
#define tables as there was earlier, which defeats the purpose of code
sharing. I admit swab code could be split from byteorder generic
(vaxendian suggests it, too). Now, if you think you can do better, please do!
There is not a bit of useless code in the patch (except for the
#if 1 and #if 0 about whether or not to define htonl and __htonl as
actual functions, or as macros).
Regards,
== Faré -=- (FR) François-René Rideau -=- (VN) Уng-Vû Bân -=- rideau@ens.fr ==
Join a project for a free reflective computing system! | 6 rue Augustin Thierry
TUNES is a Useful, Not Expedient System. | 75019 PARIS FRANCE
http://www.eleves.ens.fr:8080/home/rideau/Tunes/ -=- Reflection&Cybernethics ==