public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Michal Marek <mmarek@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-kbuild@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>,
	David Howells <dhowells@redhat.com>
Subject: Re: [RFC] possible killing of boilerplate headers by asm-generic reorg
Date: Wed, 10 Aug 2011 14:20:03 +0200	[thread overview]
Message-ID: <201108101420.03789.arnd@arndb.de> (raw)
In-Reply-To: <4E4254E1.5070909@suse.cz>

On Wednesday 10 August 2011, Michal Marek wrote:
> On 7.8.2011 23:00, Linus Torvalds wrote:
> > There is value in having <asm-generic/xyz.h> for helper headers that
> > are not complete in themselves. And for that case, we really do want
> > to have the ability for header files to just do
> > 
> >  #include <asm-generic/bitops/le.h>

There are very few of these files, and there is no reason for them to
be named asm/* or arm-generic/*. How about moving those incomplete
files into a different directory to separate the problem space?

We can e.g. move asm-generic/bitops/ to linux/bitops/

> > So I would suggest we just start a new directory, something like
> > include/default, and add it as the last entry to the search path. Then
> > we start populating it with <asm/xyz.h> files, and start removing the
> > silly 'generic-y' workaround. Let's just use the search-path instead.
> 
> But we would still have to generate the wrapper for userspace headers,
> we can't rely on any -I/usr/include/default in userspace. So
> Makefile.headersinst would still need some special handling for these
> headers.

Right. We have to deal with at least three cases here:

1. An architecture does not provide its own asm/foo.h, and we want the
   generic version to transparently be used.
2. Another architecture has an asm/foo.h that contains a few arch specific
   definitions plus an include of the generic file.
3. There is a generic file that is used as a helper from a file with a
   different name (e.g. bitops/find.h, libata-portmap.h, atomic-long.h, ...).

Simply renaming "asm-generic" to "asm" or "default/asm" with an appropriate
include path would take care of the first kind, but not of the second.
This is also easy to handle for headers exported to user space, where we
can simply copy the generic header instead of an arch specific one when
that does not exist.

The second case is still easily handled in many cases, except for the 34
generic header files that do get exported to user space (see
include/asm-generic/Kbuild). The best I can think of is to move them to
linux/include/asm-generic/asm/ and install them to
/usr/include/asm-generic/asm/ to avoid opening up another namespace
for user space headers. Any file including them would then have to be
changed to "#include <asm-generic/asm/foo.h>".

I hope that the work that David Howells is trying to push for the
separation between internal and ABI headers will help a bit to
simplify this.

	Arnd

  reply	other threads:[~2011-08-10 12:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-07 20:41 [RFC] possible killing of boilerplate headers by asm-generic reorg Al Viro
2011-08-07 21:00 ` Linus Torvalds
2011-08-10  9:52   ` Michal Marek
2011-08-10 12:20     ` Arnd Bergmann [this message]
2011-08-10 15:34     ` Linus Torvalds
2011-08-11 13:16       ` Arnd Bergmann
2011-08-11 13:25         ` Al Viro
2011-08-11 14:20           ` David Howells
2011-08-11 20:44             ` Sam Ravnborg
2011-08-11 14:25         ` Sam Ravnborg

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=201108101420.03789.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=dhowells@redhat.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=sam@ravnborg.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox