[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <op.vf7lipj67p4s8u@pikus>
Date: Wed, 21 Jul 2010 21:53:03 +0200
From: Michał Nazarewicz <m.nazarewicz@...sung.com>
To: Daniel Walker <dwalker@...eaurora.org>
Cc: linux-mm@...ck.org, Marek Szyprowski <m.szyprowski@...sung.com>,
Pawel Osciak <p.osciak@...sung.com>,
Xiaolin Zhang <xiaolin.zhang@...el.com>,
Hiremath Vaibhav <hvaibhav@...com>,
Robert Fekete <robert.fekete@...ricsson.com>,
Marcus Lorentzon <marcus.xm.lorentzon@...ricsson.com>,
linux-kernel@...r.kernel.org,
Kyungmin Park <kyungmin.park@...sung.com>,
linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added
On Wed, 21 Jul 2010 21:37:09 +0200, Daniel Walker <dwalker@...eaurora.org> wrote:
> What makes you assume that the bootloader would have these strings?
> Do your devices have these strings? Maybe mine don't have them.
I don't assume. I only state it as one of the possibilities.
> Assume the strings are gone and you can't find them, or have no idea
> what they should be. What do you do then?
Ask Google?
I have a better question for you though: assume the "mem" parameter is
lost and you have no idea what it should be? There are many parameters
passed to kernel by bootloader and you could ask about all of them.
Passing cma configuration via command line is one of the possibilities
-- especially convenient during development -- but I would expect platform
defaults in a final product so you may well not need to worry about it.
Bottom line: if you destroyed your device, you are screwed.
>>>> Imagine a developer who needs to recompile the kernel and reflash the
>>>> device each time she wants to change the configuration... Command line
>>>> arguments seems a better option for development.
>>> So make it a default off debug configuration option ..
>> I don't really see the point of doing that. Adding the command line
>> parameters is really a minor cost so there will be no benefits from
>> removing it.
> Well, I like my kernel minus bloat so that's a good reason. I don't see
> a good reason to keep the interface in a production situation .. Maybe
> during development , but really I don't see even a developer needing to
> make the kind of changes your suggesting very often.
As I've said, removing the command line parameters would not benefit the
kernel that much. It's like 1% of the code or less. On the other hand,
it would add complexity to the CMA framework which is a good reason not
to do that.
Would you also argue about removing all the other kernel parameters as
well? I bet you don't use most of them. Still they are there because
removing them would add too much complexity to the code (conditional
compilation, etc.).
I'm not saying that removing “bloat” (or unused options if you will)
from the kernel is a bad thing but there is a line where costs of
doing so negate the benefits.
--
Best regards, _ _
| Humble Liege of Serenely Enlightened Majesty of o' \,=./ `o
| Computer Science, Michał "mina86" Nazarewicz (o o)
+----[mina86*mina86.com]---[mina86*jabber.org]----ooO--(_)--Ooo--
--
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