linux-kernel - Re: [PATCH 0/2] ARM: Unify setup for Marvell SheevaPlugs and Seagate DockStars

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:	Thu, 7 Apr 2011 18:39:12 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Alexander Holler <holler@...oftware.de>
Cc:	Nico Erfurth <ne@...urth.eu>, Eric Cooper <ecc@....edu>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Nicolas Pitre <nico@...xnic.net>
Subject: Re: [PATCH 0/2] ARM: Unify setup for Marvell SheevaPlugs and
	Seagate DockStars

On Thu, Apr 07, 2011 at 11:44:02AM +0200, Alexander Holler wrote:
> Am 07.04.2011 11:37, schrieb Nico Erfurth:
>> Alexander Holler wrote:
>>
>>> I wonder how many people believe that either there will be another
>>> DockStar with the same HW and GPIOs for the LEDs but more memory (and
>>> still without sata) or that there will be another SheevaPlug with just
>>> 128MB RAM or that someone could have a reason to change the memory
>>> layout using a mem= parameter.
>>>
>>> For me all that is pretty unlikely.
>>
>> As Nicolas stated it's not just about "Oh, thats totally unlikely to
>> happen!". It is about maintainable code, if somebody looks at it in 3
>> years they should not think "WTF?!?!". Using machine ids and the
>> generated macros helps to keep the code clean and readable.
>
> Sorry, I can't agree. For me some unique hardware identifier is more  
> reasonable, than some machine id which comes from outerspace.

I agree 100% with Nicolas - using memory size is far from obvious and
is not clean and understandable.  Using memory size as a way of detecting
the machine type is far worse than just mere "silly".

We have an established API and convention in the kernel which you claim
is "from outerspace".  It's not "from outerspace" but a designed API to
allow platforms to live together in the same kernel image.  So I find
your arguments totally unreasonable.

I fully support Nicolas in rejecting your patches outright on this point
alone.
--
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/