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]
Message-ID: <CAJe_Zhdy0q8H9jhG=wXMVToUjevZk1XcGUm1oKSZvpDNZ1UdVg@mail.gmail.com>
Date:	Sun, 1 Jul 2012 18:41:44 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
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 1 July 2012 17:40, Russell King - ARM Linux <linux@....linux.org.uk> wrote:
> 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.
>
I fully agree with your point and IIRC I always add some prefix to
definitions in header files.
Private defines in a .c file, without redundant prefixes, sounded like
safe to me at the time, but perhaps I was wrong.

Thanks.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ