move libc related stuff out of platform.h

Denys Vlasenko vda.linux at googlemail.com
Fri Jul 10 10:12:53 UTC 2009


On Fri, Jul 10, 2009 at 10:46 AM, Rob Landley<rob at landley.net> wrote:
> How is the MS_BIND stuff a good idea?  Duplicating a long #ifdef staircase in
> two places doesn't really sound like an improvement.

I agree that duplicating is bad.

I don't want to handle _libc_ compat issues in platform.h,
because in order to do

#ifdnef FOO
# define FOO good_foo
#endif

one needs to #include <relevant_file.h> first. And if we do that
in platform.h, it will grow big.

I decided to do such things in libbb.h instead, directly after each
#include <relevant_file.h> which needs such treatment.

And if some headers aren't included into libbb.h because they are
specialized (like sys/mount.h), then I decided to do it whereever they
are included.

> Besides, all these
> #defines are already in a standard header file if you're building on a system
> that can actually use the result.  (If they're not in your header, that means
> the kernel headers you're using don't know about that call, and thus you
> probably shouldn't be using it.)

And if you're building on an old(er) system, but run on a newer one?
I suspect that was the original motivation for this.

> What might be better is some kind of switch you can throw to trim this
> functionality when it's not supported, to avoid a build break.  Either a
> CONFIG option for "2.6 mount options", or a single "#ifndef MS_RELATIME" to
> disable the lot of it, checking the most recent one.  (There's not much point
> in adding extra granularity, special support for a 2.6.12 kernel as distinct
> from a 2.4 kernel doesn't really seem worth the effort to me.)

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.

--
vda


More information about the busybox mailing list