public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: linux-arm-kernel@lists.infradead.org,
	lkml <linux-kernel@vger.kernel.org>, Eric Cooper <ecc@cmu.edu>
Subject: Re: [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size.
Date: Thu, 07 Apr 2011 01:22:27 +0200	[thread overview]
Message-ID: <4D9CF5B3.9020007@ahsoftware.de> (raw)
In-Reply-To: <alpine.LFD.2.00.1104061850410.28032@xanadu.home>

On 07.04.2011 01:01, Nicolas Pitre wrote:
> On Thu, 7 Apr 2011, Alexander Holler wrote:
>
>> On 06.04.2011 23:44, Nicolas Pitre wrote:
>>> On Wed, 6 Apr 2011, Alexander Holler wrote:
>>>
>>>> It is possible to differentiate a SheevaPlugs and DockStars on the basis
>>>> of the memory size.
>>>>
>>>> This makes it possible to unify both setup files.
>>>
>>> No no no !!!  This is an abomination!
>>>
>>> We are not going to reduce the amount of code under arch/arm/ with such
>>> fragile hacks.  This would create an even worse maintenance problem the
>>> day either of those devices is released with more RAM or whatever.
>>
>> DockStars are already obsolet and vanilla Linux was never supported by the
>> manufacturer (Seagate). And they never used the machine type in question.
>
> Is the code for DockStar in mainline actually useful?  If no then we may
> simply delete it.

I don't know, I can't speak for others.

>> So I don't think this in any way a fragile hack.
>
> Determining a machine type based on its amount of RAM is fragile, ugly
> and sets up a bad example for even more hacky tricks like this to crop
> up. If someone is experimenting with his SheevaPlug by giving different
> memory information in the kernel cmdline e.g. to create memory holes in
> order to test some memory allocator changes, then the kernel may think
> that it is not running on a SheevaPlug but a DockStar, and the resulting
> behavior will certainly be unexpected.

People doing such should now what they do. And the pr_info() in the 
"abomination" should be enough to give those experimenters a hint (if it 
is missing or new).

>> Anyway, it was just a suggestion.
>
> Better luck next time.

Sorry, I don't feel the need to waste my time prodcuing patches to get 
them called "abominations". Which means my willingness to post further 
patches just got below zero.

Regards,

Alexander

  reply	other threads:[~2011-04-06 23:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-06 20:35 [PATCH 0/2] ARM: Unify setup for Marvell SheevaPlugs and Seagate DockStars Alexander Holler
2011-04-06 20:35 ` [PATCH 1/2] ARM: Differentiate SheevaPlugs and DockStars on the basis of the memory size Alexander Holler
2011-04-06 21:44   ` Nicolas Pitre
2011-04-06 22:45     ` Alexander Holler
2011-04-06 23:01       ` Nicolas Pitre
2011-04-06 23:22         ` Alexander Holler [this message]
2011-04-07  2:55           ` Nicolas Pitre
2011-04-07  8:55           ` Alexander Clouter
2011-04-07 21:31             ` Alexander Holler
2011-04-07 21:44               ` Alexander Clouter
2011-04-07 21:59                 ` Alexander Holler
2011-04-07 22:08               ` Russell King - ARM Linux
2011-04-07 23:04                 ` Alexander Holler
2011-04-08  7:24                   ` Russell King - ARM Linux
2011-04-08  8:38                     ` Alexander Holler
2011-04-09  8:29                   ` Bernd Petrovitsch
2011-04-10 18:14                     ` Alexander Holler
2011-04-10 19:29                       ` Alexander Holler
2011-04-06 23:23         ` Eric Cooper
2011-04-06 20:35 ` [PATCH 2/2] ARM: Remove machine type dockstar (use sheevaplug instead) Alexander Holler
2011-04-06 21:02   ` Nicolas Pitre
2011-04-06 21:43     ` Alexander Holler
2011-04-06 22:50 ` [PATCH 0/2] ARM: Unify setup for Marvell SheevaPlugs and Seagate DockStars Nico Erfurth
2011-04-07  9:20   ` Alexander Holler
2011-04-07  9:37     ` Nico Erfurth
2011-04-07  9:44       ` Alexander Holler
2011-04-07 17:39         ` Russell King - ARM Linux
2011-04-08  3:38           ` Alexander Holler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D9CF5B3.9020007@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=ecc@cmu.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nico@fluxnic.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox