Re: [RFC] possible killing of boilerplate headers by asm-generic reorg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 10, 2011 at 2:52 AM, Michal Marek <mmarek@xxxxxxx> wrote:
>
> 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.

So at least for some cases, that isn't an issue, because these things
wouldn't be exported anyway.

An example of this kind of situation that we had recently was the x86
use of "rdrand()", where the logical thing to do was to create a new
arch-specific include file containing "arch_get_random_word()", and
have a default implementation that just returned 0.

That's actually annoyingly hard to do.

You can do it by (a) *not* creating a new header file and (b) using an
extern declaration and (c) using a weak function that returns 0, and
that way you don't need to touch any architecture files. But I really
wanted an inline function, because the whole point was to not generate
any code for the case of the architecture not supporting it.

Of course, you can also do the same thing by just introducing another
CONFIG option, and hide the architectures that don't support it that
way. We've done that lots of time. It works, but it's annoying and
makes the code harder to read.

Or you can do it by creating the default file, and then editing EVERY
SINGLE ARCHITECTURE. Which just sucks.

This has come up before, for similar situations - wanting to implement
optional architecture capabilities without having to worry about
architectures that don't support it.

                         Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux