public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Wen Congyang <wency@cn.fujitsu.com>,
	tglx@linutronix.de, Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2 v2] x86: add max_addr boot option
Date: Thu, 14 Jun 2012 15:00:12 -0500	[thread overview]
Message-ID: <4FDA42CC.2090807@landley.net> (raw)
In-Reply-To: <4FD94738.6030500@jp.fujitsu.com>

On 06/13/2012 09:06 PM, Kamezawa Hiroyuki wrote:
>> You're adding an option because you consider it less confusing for your
>> end users who are digging into kernel parameters, but you will set this
>> new option for your users because they haven't got the information to
>> set it themselves?
>>
> 
> My users don't need to know about hardware settings and the meaning of
> kernel params. They'll just do as we ask to do.

So you're adding a new feature that only you will use, because the
existing way of doing it confuses... you.

>> So you're saying there are already two ways to do this, but you want to
>> add a third to be less confusing for end users who are modifying the
>> linux kernel boot parameters by hand using information only you can
>> supply to them?
>>
>> I'm confused...
>>
> 
> I'm just saying current mem= implemenation seems buggy because spec. and
> impl. doesn't match. So, we're just afraid that someone other than us
> will fix it and break our assumption how mem= works. It's dangerous to
> build a production on a feature where spec. and impl. doesn't match.
> So, we proposed to add max_addr= option for avoiding that situation.

So fix the spec, or fix the implementation. Don't add a random new
duplicate way to do the same thing because you're afraid that open
source code might change, but somehyow the new code you propose to add
won't (presumably due to being so profoundly uninteresting to the rest
of the world that nobody will notice it's there).

Sigh.  On arm you can go "mem=size@start", which can be repeated. I.E.
you can, on the kernel command line, tell it where all the chunks of
physical memory it should use actually live. Letting x86 do that might
be nice. Adding a clipping option to the normal memory probing, so
memory probing has to fail in a certain specific way in order for this
to even apply? Not so much...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

  reply	other threads:[~2012-06-14 20:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-11  8:44 [PATCH 1/2 v2] x86: add max_addr boot option Wen Congyang
2012-06-11  8:46 ` [PATCH 2/2 v2] x86: reimplement mem " Wen Congyang
2012-06-11 17:35 ` [PATCH 1/2 v2] x86: add max_addr " Bjorn Helgaas
2012-06-12  6:29   ` Wen Congyang
2012-06-12 11:30     ` Bjorn Helgaas
2012-06-13  1:55       ` Kamezawa Hiroyuki
2012-06-13  4:59         ` Rob Landley
2012-06-14  2:06           ` Kamezawa Hiroyuki
2012-06-14 20:00             ` Rob Landley [this message]
2012-06-11 21:15 ` H. Peter Anvin
2012-06-12  6:26   ` Wen Congyang
2012-06-12 16:10     ` H. Peter Anvin
2012-06-13  2:21       ` Kamezawa Hiroyuki
2012-06-13  3:29         ` H. Peter Anvin
2012-06-13  5:20           ` Kamezawa Hiroyuki
2012-06-13  5:36           ` Wen Congyang

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=4FDA42CC.2090807@landley.net \
    --to=rob@landley.net \
    --cc=bhelgaas@google.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=wency@cn.fujitsu.com \
    --cc=x86@kernel.org \
    /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