[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <op.vf8nkct57p4s8u@pikus>
Date: Thu, 22 Jul 2010 11:34:50 +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 23:01:42 +0200, Daniel Walker <dwalker@...eaurora.org> wrote:
> On Wed, 2010-07-21 at 22:56 +0200, Michał Nazarewicz wrote:
>> On Wed, 21 Jul 2010 22:45:43 +0200, Daniel Walker <dwalker@...eaurora.org> wrote:
>> > Your not hearing the issues.. IT'S TOO COMPLEX! Please remove it.
>>
>> Remove what exactly?
>
> Remove the command line option and all related code, or make it all a
> debug option.
How convenient... you have stripped the part of my mail where I described
why this is request have no sense. I'll quote myself then:
>> The command line parameter? It's like 50 lines of code, so I don't
>> see any benefits.
As such, I'm not going to add bunch of #ifdefs just to remove 50 lines
of code.
>> The possibility to specify the configuration? It would defy the whole
>> purpose of CMA, so I won't do that.
Simply as that. We work with a platform where whole of the functionality
provided by CMA is required (many regions, region start address, region
alignment, device->region mapping).
This means, what I keep repeating and you keep ignoring, that the complexity
will be there if not as a parsing code then moved to the platform
initialisation code and drivers code.
One of the purposes of CMA is to hide the complexity inside CMA framework so
device driver authors and platform maintainers can use a simpler interface.
Some time age (like year or two) I've posted some other solution to the
problem which served our purpose just well and had very little complexity
in it. Unfortunately, customising that solution was quite hard (required
changes to a header file and adding modifying code for reserving space).
Also, in this old solution, adding or removing regions required device
drivers to be modified.
This was not nice, not nice at all. True, however, the core wasn't complex.
So when you say remove the complicity I say: I have been there, it's ugly.
> Arguing with me isn't going to help your cause.
It's you who keep repeating “remove it, it's to complex” without
hearing my arguments. I keep trying to show that all of the
functionality is required and is being used on our development
platform.
If your hardware does not require that complexity... well, you're one
lucky man. Unfortunately, we are not, and we need a complex solution
to work with complex hardware.
--
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