linux-kernel - Re: [PATCH V2 5/6] x86: add CONFIG_ARM

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 1 Jul 2012 13:10:08 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Jassi Brar <jaswinder.singh@...aro.org>
Cc:	Alessandro Rubini <rubini@...dd.com>, linux-arch@...r.kernel.org,
	giancarlo.asnaghi@...com, arnd@...db.de,
	gregkh@...uxfoundation.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
	hpa@...or.com, linux-arm-kernel@...ts.infradead.org,
	alan@...ux.intel.com
Subject: Re: [PATCH V2 5/6] x86: add CONFIG_ARM_AMBA, selected by STA2X11

On Sun, Jul 01, 2012 at 05:28:16PM +0530, Jassi Brar wrote:
> On 1 July 2012 16:29, Russell King - ARM Linux <linux@....linux.org.uk> wrote:
> > On Sun, Jul 01, 2012 at 12:44:01PM +0200, Alessandro Rubini wrote:
> >> How should I address the problem? (original code, published on
> >> sourceforge was simply replicating a number of amba drivers into pci
> >> drivers, but I don't think massive code duplication is ever sensible,
> >> thus I preferred to reuse the existing drivers).
> >
> > I think the answer is... those primecell drivers need fixing in some way.
> > Re-defining CS, DS and ES in drivers is rather silly given that they're
> > x86 segment register names - so if PL330 can be fixed to make its names
> > more specific, that sorts it out.
> >
> I am OK prefixing the regs with PL330_ or somesuch.
> 
> The CS, DS and ES regs were named so as to match exactly the
> terminology of the PL330 manual. So apparently even the ARM Ltd didn't
> imagine ARM and X86 galaxies colliding so soon :)

Whatever it says in documentation is neither here nor there.  We're humans,
we can re-interpret, and we are capable of adding prefixes to names when
they're stupidly chosen.

Notice how I added MMCI_ and MCI_ to the register definitions for PL180
for example.  I always do that kind of thing as a rule to avoid these kinds
of problems right from the outset, and I don't understand why others don't
do the same.  We've been through soo many "this symbol clashes with
something else in the kernel tree" now that we really should be doing this
automatically, and not waiting for the clash to happen.
--
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/