Re: [PATCH 2/4] mm: cma: Contiguous Memory Allocator added

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 21 Jul 2010 21:37:09 +0200, Daniel Walker <dwalker@xxxxxxxxxxxxxx> 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]