On Fri, Jul 10, 2009 at 10:46 AM, Rob Landley<[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
