On Wed, 2011-07-13 at 19:34 +0200, Karel Zak wrote: > On Wed, Jul 13, 2011 at 04:54:22PM +0200, Sami Kerola wrote: > > On Wed, Jul 13, 2011 at 14:12, Karel Zak <kzak@xxxxxxxxxx> wrote: > > > On Wed, Jul 13, 2011 at 01:33:03PM +0200, Sami Kerola wrote: > > >> On Wed, Jul 13, 2011 at 06:05, Davidlohr Bueso <dave@xxxxxxx> wrote: > > >> > I don't think we should always rely on having the kernel headers, that's > > >> > why the fallback is provided. > > >> [snip] > > >> > I think with this patch we address the issue without removing our > > >> > fallback. > > >> > > >> The preprocessor directive bellow is problematic. I don't see where, > > >> or how, it might get satisfied so I am afraid the 'fall back' is > > >> always in use regardless whether an user has kernel headers or not. > > >> > > >> #ifdef KERNEL_INCLUDES_ARE_CLEAN > > >> > > >> To fix that I modified the patch to use autoconf to check whether each > > >> necessary header is present, and use them if possible. Notice that > > >> Dave that I wrote your name to Reviewed-by patch line so it would be > > >> nice to hear that you're OK with the change. See the attachment, or > > >> pull from my repository. > > > > > > This is wrong way... the kernel types (e.g. u32, s64) are > > > *unexpected* in util-linux. The new code should not use this junk. We > > > have <stdint.h> and <inttypes.h>. > > > > Fixed. > > > > > The mkfs.minix should not depend on kernel headers. It's normal that > > > we use our own (on kernel independent) copy of FS superbloks. See > > > libblkid code. > > > > By depend do you mean; > > > > 1. Distrust that kernel headers are present, and have alternative > > copy, but use them when they are present. > > 2. Use always util-linux copy of structures ignoring the possible > > header even they might be present. > > Ignore kernel, 2. is right in this case. Yep, I agree. Karel, if you have no objections then please apply my patch as it does fix the sb mismatch. Thanks. > > Karel -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
