linux-kernel - Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5693F5B7.8040608@ti.com>
Date:	Mon, 11 Jan 2016 20:34:31 +0200
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	Pali Rohár <pali.rohar@...il.com>
CC:	<tony@...mide.com>, <linux@....linux.org.uk>, <pavel@....cz>,
	<linux-omap@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Ivaylo Dimitrov <freemangordon@....bg>
Subject: Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator

On 04/01/16 15:04, Ivaylo Dimitrov wrote:
> Hi Tomi,
> 
> On  4.01.2016 13:37, Tomi Valkeinen wrote:
>>
>> We probably need exactly the same for omapdrm, as omapfb is on the way
>> to being deprecated. And sounds to me that we probably need similar for
>> other devices which try to do large allocations (camera? video
>> decoders?).
>>
> 
> Re omapdrm - I guess it wouldn't be hard for omapdrm to use the same
> preallocated memory, when/if it is needed. Though I know nothing about
> omapdrm, so can't really tell.
> 
> If not mistaken, camera driver uses sg lists. DSP needs such a memory,
> but anyway it(driver) was removed from mainline, with no signs/hope to
> be returned anytime soon.

I don't know about omap3 (if that's what you're talking about), but
generally, I think it depends very much on the IPs used. I don't think
all capture IPs support sg.

>> So I really think this should be somehow be a general option for any
>> device.
>>
> 
> Then maybe add the relevant people in CC, so we to start some kind of
> discussion. But until such a general option exists, I think it makes
> sense to apply the $subject patch, we can easily fix it to use whatever
> general purpose API might the discussion come up with. As it is now,
> omapfb simply cannot be used to play any video with sane resolution
> (without preallocated memory that is), unless this is the only thing the
> device does. And even then it is not assured.

The patch itself looks fine to me, and I have no problem adding
temporary code to help solve use cases. Except when they add new
userspace APIs, which is what's done here. I've been bitten too many
times by an userspace API that I need to maintain forever, making new
development difficult. That's the reason I'm (maybe overly) cautious here.

I also want to point out that the patch was posted two years ago. And
now there's a ping for the first time. It cannot be a huge problem to a
lot of people.

Adding to that is the fact that omapfb is now in maintenance mode, and
all new development is done for omapdrm.

So, I'm not very enthusiastic about adding this feature as an omapfb
specific boot parameter.

 Tomi

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)