All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: kerolasa@gmail.com
Cc: dave@gnu.org, util-linux@vger.kernel.org
Subject: Re: [PATCH] minix: v3 super-block does not have s_state field
Date: Wed, 13 Jul 2011 19:34:30 +0200	[thread overview]
Message-ID: <20110713173430.GD3486@nb.net.home> (raw)
In-Reply-To: <CAG27Bk2m+d=N9yVTSbByzhfkMUmP-d7heQXS643uWE3n+05+Mw@mail.gmail.com>

On Wed, Jul 13, 2011 at 04:54:22PM +0200, Sami Kerola wrote:
> On Wed, Jul 13, 2011 at 14:12, Karel Zak <kzak@redhat.com> 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@gnu.org> 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.

    Karel
-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2011-07-13 17:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-12 15:50 [PATCH] minix: v3 super-block does not have s_state field Sami Kerola
2011-07-13  4:05 ` Davidlohr Bueso
2011-07-13 11:33   ` Sami Kerola
2011-07-13 12:12     ` Karel Zak
2011-07-13 14:54       ` Sami Kerola
2011-07-13 17:34         ` Karel Zak [this message]
2011-07-14  2:03           ` Davidlohr Bueso
2011-07-14  9:18             ` Karel Zak
2011-07-14 15:47               ` Sami Kerola
2011-07-18 22:19                 ` Karel Zak
2011-07-20 18:53                   ` Sami Kerola
2011-07-21 11:21                     ` Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110713173430.GD3486@nb.net.home \
    --to=kzak@redhat.com \
    --cc=dave@gnu.org \
    --cc=kerolasa@gmail.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.