[PATCH] standardize on KERNEL_VERSION(a,b,c) test

[Robert P. J. Day]

On Thu, 30 Mar 2006, Bernhard Fischer wrote:

> On Thu, Mar 30, 2006 at 07:51:04AM -0500, Robert P. J. Day wrote:

... snip ...

> >diff -pru busybox.orig/e2fsprogs/mke2fs.c busybox/e2fsprogs/mke2fs.c
> >--- busybox.orig/e2fsprogs/mke2fs.c	2006-03-29 07:43:43.000000000 -0500
> >+++ busybox/e2fsprogs/mke2fs.c	2006-03-30 07:30:30.000000000 -0500
> >@@ -33,6 +33,7 @@
> > #include "e2p/e2p.h"
> > #include "ext2fs/ext2fs.h"
> > #include "util.h"
> >+#include "platform.h"
>
> That include sounds wrong.
> e2fsbb.h includes libbb.h which includes platform.h

  hard to believe but i've been grappling with what to think about the
layout of BB header files for a few days.

  obviously, including "platform.h" is redundant but it doesn't hurt
since all of the header files are protected against multiple inclusion
so that's certainly not going to break anything, but there's more to
it than that.

  as it stands now, i think the BB header files are unnecessarily
confusing simply because they're nested.  if you take a quick look at,
say, libbb.h, it starts off with:

#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <termios.h>
#include <stdint.h>
...

so including libbb.h *already* drags in a number of system header
files.  obviously, that means that, once you include "libbb.h", you no
longer need to include any of the above, right?  and yet, if you pick
a random source file under libbb/, chances are it will not only be
including "libbb.h" but at least (redundantly) one of the above.  (in
fact, i defy you to find a source file in libbb/ that doesn't contain
that kind of redundancy).

  so what to do about all of *that* then?  coincidentally, just a few
weeks ago, i was reading a software design book that *strongly*
discouraged the concept of nested header files.  its advice was that:

1) each header file should have a clear and focused purpose,
2) each source file should include precisely those header files that
   it needs and no more, and
3) you shouldn't create humongous, catch-all header files (like
   busybox.h and libbb.h) whose only purpose is to let you be somewhat
   lazy about having to list the includes you really need.

here's a perfect example of the chaotic structure of the current
header files.  consider the source file libbb/error-msg.c

================================
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <stdlib.h>
#include "libbb.h"

void bb_error_msg(const char *s, ...)
{
    va_list p;

    va_start(p, s);
...

  first, as we've established, there's no need to include <stdio.h>
since that's already included by "libbb.h".  but it's actually worse
than that.  the "va_list" stuff is defined in <stdarg.h> but that file
is *not* included by this source file.  no problem, though, since it
comes via "libbb.h".

  in effect, by letting "libbb.h" be this monstrous catch-all header
file that grabs most everything else, it allows the programmer to be
incredibly sloppy about which other header files to include.  yes, it
works, but it just seems "messy" to me.

rday