All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] romfs: cleanup romfs_fs.h
Date: Tue, 7 Apr 2009 19:52:43 +0200	[thread overview]
Message-ID: <20090407175243.GC13089@uranus.ravnborg.org> (raw)
In-Reply-To: <20090407174417.GC14462@lst.de>

On Tue, Apr 07, 2009 at 07:44:17PM +0200, Christoph Hellwig wrote:
> On Tue, Apr 07, 2009 at 07:44:57PM +0200, Sam Ravnborg wrote:
> > On Tue, Apr 07, 2009 at 06:07:08PM +0200, Christoph Hellwig wrote:
> > > There's no kernel-only content in it anymore, so move it to header-y
> > > and remove the superflous #ifdef __KERNEL__.
> > 
> > today there is no difference between header-y and unifdef-y.
> > We pass everything through unifdef these days.
> 
> The __KERNEL__ removal still applies, and as long as we have two
> different variables it should use the correct one.
> 
> But why do you send all through unifdef anyway?  That's a pretty bad
> signal to send when we try to get people to do cleanly seprated headers.

We saw too many cases where headers was not assigned to unifdef-y
after introducing "#ifdef __KERNEL__".
So we integrated the install and unifdef step to avoid this.
And with the header stuff in kbuild redesigned the cost was acceptable to do so.

When I get some spare time I plan to re-implement the unifdef tool
so it does exactly what we want it to do so we can skip the
perl/unifdef stuff we have today.

And I should sent a patch to Linus to get rid of unifdef-y so not to
confuse people.

	Sam

      reply	other threads:[~2009-04-07 17:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-07 16:07 [PATCH] romfs: cleanup romfs_fs.h Christoph Hellwig
2009-04-07 17:44 ` Sam Ravnborg
2009-04-07 17:44   ` Christoph Hellwig
2009-04-07 17:52     ` Sam Ravnborg [this message]

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=20090407175243.GC13089@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@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.