Re: ntohl and others
Fare Rideau (rideau@ens.fr)
Thu, 16 Oct 1997 14:59:01 +0200 (MET DST)
About ntohl et al:
in my patch available as
http://www.eleves.ens.fr:8080/home/rideau/files/byteorder-2.1.57.patch.gz
announced recently, I tried to clarify all the mess about htonl:
In that patch,
* I moved everything but optimized definitions
and little/big endian declaration out of architecture-specific files.
Arch-specific files become small and readable.
Shared code is put in common files that are easier to modify:
linux/byteorder_*.h.
* I express htonl et al in terms of cpu_to_be32 et al;
of course, Vaxlinux porters will not be able to do that,
but that's been clustered in
linux/byteorder_little_endian and linux/byteorder_big_endian.h,
so that's not a problem.
* I remove the fact that be32_to_cpu and al be in kernel mode only;
instead they are static __inline__ __const__ functions,
which ensures both efficiency, type checking, and absence of variable
name clash or multiple side effects.
* I hope that making these symbols visible is is not a problem with
namespace pollution; if it is, well, then, I think that prefixing
every symbol with __linux__ should be ok, with kernel mode enabling
#define's that remove the prefix.
* I keep all optimizations present in any of the existing byteorder.h files
* I keep htonl et al. as extern inline functions,
to ensure compatibility with someone who'd require it (???)
but I propose a #if 0 version of the thing where it's just a #define.
>> (3) Why on earth do you want the address of ntohl? It's not like
>> you need to change endianness at runtime...
>
> No, but maybe the choice of converting or not converting. Imagine a
> function making a data structure for host or network use. When asked for
> a host order data structure, a parameter can be passed to the function
> that does that conversion (nothing), and when a network order structure
> is wanted, htonl can be passed.
>
That's most inefficient (push/pop and indirect call).
switch() seems better. Plus you can do lots of work in a switch
assuming the same byteorder, instead of calling at *every* conversion.
See how I do things in my ufs-2.1.57.patch.gz (which btw doesn't
work, since it's not updated to the new dcache structure of the kernel).
> This is just an example I just made up, but why should the kernel's
> include files tell people what to code?
And why should people include kernel header files to begin with?
== 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 ==