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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 30 Mar 2019 02:32:35 +0000
From:   "Zengtao (B)" <prime.zeng@...ilicon.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     "labbott@...hat.com" <labbott@...hat.com>,
        "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
        "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
        Todd Kjos <tkjos@...roid.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
        Arve Hjønnevåg <arve@...roid.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        Martijn Coenen <maco@...roid.com>,
        "Christian Brauner" <christian@...uner.io>
Subject: RE: [PATCH] staging: android: ion: refactory ion_alloc for kernel
 driver use

>-----Original Message-----
>From: Greg Kroah-Hartman [mailto:gregkh@...uxfoundation.org]
>Sent: Saturday, March 30, 2019 12:04 AM
>To: Zengtao (B) <prime.zeng@...ilicon.com>
>Cc: labbott@...hat.com; sumit.semwal@...aro.org;
>devel@...verdev.osuosl.org; Todd Kjos <tkjos@...roid.com>;
>linux-kernel@...r.kernel.org; dri-devel@...ts.freedesktop.org;
>linaro-mm-sig@...ts.linaro.org; Arve Hjønnevåg <arve@...roid.com>;
>Joel Fernandes <joel@...lfernandes.org>; Martijn Coenen
><maco@...roid.com>; Christian Brauner <christian@...uner.io>
>Subject: Re: [PATCH] staging: android: ion: refactory ion_alloc for kernel
>driver use
>
>On Sat, Mar 30, 2019 at 02:40:16AM +0800, Zeng Tao wrote:
>> There are two reasons for this patch:
>> 1. There are some potential requirements for ion_alloc in kernel
>> space, some media drivers need to allocate media buffers from ion
>> instead of buddy or dma framework, this is more convient and clean
>> very for media drivers. And In that case, ion is the only media buffer
>> provider, it's more easier to maintain.
>
>As this really is just DMA, what is wrong with the existing dma framework
>that makes it hard to use?  You have seen all of the changes recently to it,
>right?

The current dma framework is powerful enough(to me, and more complex ^_^)
, CMA, IOMMU are all integrated, it's good. But buffer sharing, statistics, debug,
 are not so friendly for media drivers(each driver has to do all, but duplicate jobs).

>
>thanks,
>
>greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ