Messages in this thread |  | | | Subject | Re: ntohl and others | | Date | Thu, 16 Oct 1997 14:59:01 +0200 (MET DST) | | From | Fare Rideau <> |
| |
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 ==
|  |