linux-kernel - Re: [PATCH 2/2] x86: Move PCI IO ECS code to x86/pci

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Jun 2008 15:26:53 -0300
From:	"Glauber Costa" <glommer@...il.com>
To:	"Robert Richter" <robert.richter@....com>
Cc:	"Arjan van de Ven" <arjan@...radead.org>,
	"Yinghai Lu" <yhlu.kernel@...il.com>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	"Andi Kleen" <andi@...stfloor.org>
Subject: Re: [PATCH 2/2] x86: Move PCI IO ECS code to x86/pci

On Fri, Jun 13, 2008 at 3:16 PM, Robert Richter <robert.richter@....com> wrote:
> On 13.06.08 14:02:46, Glauber Costa wrote:
>> > diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c
>> > index 5c2799c..15f505d 100644
>> > --- a/arch/x86/pci/amd_bus.c
>> > +++ b/arch/x86/pci/amd_bus.c
>> > @@ -1,5 +1,9 @@
>> >  #include <linux/init.h>
>> >  #include <linux/pci.h>
>> > +#include "pci.h"
>> > +
>> > +#ifdef CONFIG_X86_64
>>
>> Please, don't do that. We are in an ongoing effort to cleanup the
>> remaining ifdefs in x86 code, and adding more of them would just make
>> it harder.
>> If you really need it, move the common part to a separate file (avoid
>> the _32 and _64 naming), and have it compiled conditionally on your
>> architecture.
>
> Ok, so what about shared code? Keep all this in separate files:
> amd_bus.c, (amd_bus_32.c), amd_bus_64.c, (amd_bus.h)?
>
> Is the strategy to avoid #ifdefs and instead use the flags in
> Makefiles? My intention was to coalesce the files. Maybe I was wrong
> here.

The strategy is to coalesce the files if they do the same thing. If
you can find an implementation that is shared
between both, it is surely the most preferable option among them all.
Even if it takes more time.

For some of them, this is obviously not intrinsically possible. That's
the case for example, of the .S files that touch deep details of the
architectures. (ok, ok, _some_ of that code might well be shared in
the future). Another example, is the page headers. Part of it
were kept in page_32.h and page_64.h.

If not, ifdefs in the .h file are probably okay, if they can be used
to avoid them in .c code.

But of course, those things are not carved in stone. If you really
think that ifdef should go there, feel free to do it, with a good
justification.

-- 
Glauber  Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/