move libc related stuff out of platform.h

[Denys Vlasenko]

On Saturday 11 July 2009 05:37, Rob Landley wrote:
> > I decided to do such things in libbb.h instead, directly after each
> > #include <relevant_file.h> which needs such treatment.
> 
> The problem is that this mixes busybox knowledge with platform knowledge.
> 
> Essentially, a different platform is a different build environment.  Linux on 
> powerpc is a different build environment from x86-64 glibc Linux, you need a 
> special compiler and libraries to build it, and a special runtime environment 
> (hardware or emulator) to test the result.  Linux on uClibc is also a different 
> build environment, one which most people don't have lying around, so they 
> can't easily test their changes against it.

Yes. But. If you want to do:

#ifndef FOO
# define FOO valid_value_for_foo
#endif

you need to #include <header_for_foo.h> BEFORE the above fragment.

And these #includes are in libbb.h, not in platform.h!

If we'll try to do #ifndef/#define/#endif dance in platform.h,
it will soon have many #includes, and basically will turn into libbb.h

But we already have libbb.h

> Linux developers have to modify libbb.h to add functionality all the time.

It is not a problem. libbb.h logically can be seen as having "sections":


#inclides

#ifndef/#define/#endif fixes
other libc-related fixes (like "extern char **environ;")

busybox stuff per se


and as long as "libc fixes" stay in their part of the file
instead of being smeared throughout it, it does not
create a mess.



> The horrible, horrible, horrible history of loop.c is one example of where we 
> couldn't quite avoid this, and had to settle for minimizing it.  Once upon a 
> time I managed to localize the horribleness to an #else for the 2.4 kernel 
> (look at the libbb/loop.c part of "git show 6a6798b8e47c7"), and I'd hoped it 
> could go away entirely when the 2.4 kernel finally fell off of people's radars.  
> (Keep in mind 2.6 had only been out for a couple years at the time, and it was 
> so new some distros most recent releases were still using 2.4.)
> 
> Unfortunately, looking at it now, none of the old horribleness ever expired, 
> and instead new #ifdefs grew up around it...
> 
> Um, I think this is wrong:
> 
> +
> +/* For 2.6, use the cleaned up header to get the 64 bit API. */
> +/* linux/loop.h relies on __u64. Make sure we have that as a proper type
> + * until userspace is widely fixed. */
> +# if (defined __INTEL_COMPILER && !defined __GNUC__) \
> +  || (defined __GNUC__ && defined __STRICT_ANSI__)
> 
> What does __INTEL_COMPILER or __STRICT_ANSI__ have to do with a linux kernel 
> header?  The file "linux/loop.c" is exported by the kernel source via "make 
> headers_install".  It has nothing to do with your compiler, it's a Linux 
> kernel header.  It's supposed to match your Linux kernel version, not your 
> compiler version.  (And technically it's your C library that the kernel 
> headers are exported to, not your compiler at all.)
> 
> +__extension__ typedef long long __s64;
> +__extension__ typedef unsigned long long __u64;
> +# endif
> +# include <linux/loop.h>
> 
> The linux/loop.h header #includes either asm/types.h or linux/types.h 
> (depending on kernel version) to get the definition of __u64.  There's a 
> comment to that effect in the kernel headers, which come from the Linux kernel.  
> If somebody's build environment isn't getting that, then their kernel headers 
> are broken.  (Most likely because they weren't exported properly.)
> 
> Busybox really shouldn't be working around obvious bugs in people's build 
> environments, that way lies madness.

I guess it's vestigial. Linux headers have improved (slowly) over time.


> It's a balancing act, but if you accept "simple" is one of the virtues of 
> busybox, accumuluating cruft is bad.

"Simple" is important for me when in ends up in the binary.
If a bit of cruft lingers in the source tree, it is not that critical.
Like devfs stuff. There may still be users in the wild.
Why cleaning it up now? It does not buy us a single saved byte
in the binary.


> > Feel free to send a patch for CONFIG option for "2.6 mount options".
> >
> > Another possible thing is to just wait a year and then declare that
> > whoever still uses 2.6.12 instead of migrating to something
> > less antiquated (less antiquated within 2.6.x world)
> > is going to suffer, and delete the ifdefs.
> 
> I'd strongly lean towards the second.

Me too.

--
vda