Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Daniel Vetter]

On Wed, Feb 15, 2017 at 12:15:26PM +, Mark Brown wrote:
> On Tue, Feb 14, 2017 at 09:59:55PM +0200, Laurent Pinchart wrote:
> > On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:
> 
> > > ADF was probably the best example in this. KMS also took a while until all
> > > the fbdev wheels have been properly reinvented (some are still the same 
> > > old
> > > squeaky onces as fbdev had, e.g. fbcon).
> 
> > > And I don't think destaging ION is going to be hard, just a bit of
> > > work (could be a nice gsoc or whatever).
> 
> > Oh, technically speaking, it would be pretty simple. The main issue is to 
> > decide whether we want to commit to the existing ION API. I don't :-)
> 
> Right, we need to figure out what people should be doing and let them
> work on it.  At the minute anyone who wants to use this stuff in
> mainline is kind of stuck as attempts to add ION drivers get pushback
> 
>https://lkml.org/lkml/2016/11/7/806
> 
> but so do attempts to do something different (there was a statement in
> that thread that new ION drivers could be added if we could ever figure
> out bindings but I'm not sure there's any prospect of that).  There's no
> clear direction for people to follow if they want to make progress.

Hm, this feels like a misunderstanding ... the unix device memory
allocator discussion is all about how to solve the userspace side on a
generic system (i.e. when you can't just hardcode everything in gralloc).
It's not really about where to actually allocate the kernel memory, for
that I think ION still looks as reasonable as anything else.

We just need to get around to working down the destaging todo items and
push it into something like drivers/gpu/ion or whatever. Feel free to cc
me and Laura and dri-devel on any such effort, this has been stuck way too
long.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Mark Brown]

On Tue, Feb 14, 2017 at 09:59:55PM +0200, Laurent Pinchart wrote:
> On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:

> > ADF was probably the best example in this. KMS also took a while until all
> > the fbdev wheels have been properly reinvented (some are still the same old
> > squeaky onces as fbdev had, e.g. fbcon).

> > And I don't think destaging ION is going to be hard, just a bit of
> > work (could be a nice gsoc or whatever).

> Oh, technically speaking, it would be pretty simple. The main issue is to 
> decide whether we want to commit to the existing ION API. I don't :-)

Right, we need to figure out what people should be doing and let them
work on it.  At the minute anyone who wants to use this stuff in
mainline is kind of stuck as attempts to add ION drivers get pushback

   https://lkml.org/lkml/2016/11/7/806

but so do attempts to do something different (there was a statement in
that thread that new ION drivers could be added if we could ever figure
out bindings but I'm not sure there's any prospect of that).  There's no
clear direction for people to follow if they want to make progress.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Benjamin Gaignard]

2017-02-14 20:59 GMT+01:00 Laurent Pinchart :
> Hi Daniel,
>
> On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:
>> On Tue, Feb 14, 2017 at 8:39 PM, Laurent Pinchart wrote:
>> > On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
>> >> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
>> >>> This is the core of simple allocator module.
>> >>> It aim to offert one common ioctl to allocate specific memory.
>> >>>
>> >>> version 2:
>> >>> - rebased on 4.10-rc7
>> >>>
>> >>> Signed-off-by: Benjamin Gaignard 
>> >>
>> >> Why not ION? It's a bit a broken record question, but if there is a
>> >> clear answer it should be in the patch ...
>> >
>> > There's a bit of love & hate relationship between Linux developers and
>> > ION. The API has shortcomings, and attempts to fix the issues went
>> > nowhere. As Laura explained, starting from a blank slate (obviously
>> > keeping in mind the lessons learnt so far with ION and other similar APIs)
>> > and then adding a wrapper to expose ION on Android systems (at least as an
>> > interim measure) was thought to be a better option. I still believe it is,
>> > but we seem to lack traction. The problem has been around for so long that
>> > I feel everybody has lost hope.
>> >
>> > I don't think this is unsolvable, but we need to regain motivation. In my
>> > opinion the first step would be to define the precise extent of the
>> > problem we want to solve.
>>
>> I'm not sure anyone really tried hard enough (in the same way no one
>> tried hard enough to destage android syncpts, until last year). And
>> anything new should at least very clearly explain why ION (even with
>> the various todo items we collected at a few conferences) won't work,
>> and how exactly the new allocator is different from ION. I don't think
>> we need a full design doc (like you say, buffer allocation is hard,
>> we'll get it wrong anyway), but at least a proper comparison with the
>> existing thing. Plus explanation why we can't reuse the uabi.
>
> I've explained several of my concerns (including open questions that need
> answers) in another reply to this patch, let's discuss them there to avoid
> splitting the discussion.
>
>> Because ime when you rewrite something, you generally get one thing
>> right (the one thing that pissed you off about the old solution), plus
>> lots and lots of things that the old solution got right, wrong
>> (because it's all lost in the history).
>
> History, repeating mistakes, all that. History never repeats itself though. We
> might make similar or identical mistakes, but there's no fatality, unless we
> decide not to try before even starting :-)
>
>> ADF was probably the best example in this. KMS also took a while until all
>> the fbdev wheels have been properly reinvented (some are still the same old
>> squeaky onces as fbdev had, e.g. fbcon).
>>
>> And I don't think destaging ION is going to be hard, just a bit of
>> work (could be a nice gsoc or whatever).
>
> Oh, technically speaking, it would be pretty simple. The main issue is to
> decide whether we want to commit to the existing ION API. I don't :-)

I think that Laura have give her felling about ION when commenting the previous
version of this patchset:
https://lkml.org/lkml/2017/1/25/76

>
> --
> Regards,
>
> Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Benjamin Gaignard]

2017-02-14 20:30 GMT+01:00 Laurent Pinchart :
> Hi Benjamin,
>
> Thank you for the patch. I've CC'ed the linux-api mailing list.
>
> On Monday 13 Feb 2017 15:45:05 Benjamin Gaignard wrote:
>> This is the core of simple allocator module.
>> It aim to offert one common ioctl to allocate specific memory.
>>
>> version 2:
>> - rebased on 4.10-rc7
>>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>  Documentation/simple-allocator.txt  |  81 +++
>>  drivers/Kconfig |   2 +
>>  drivers/Makefile|   1 +
>>  drivers/simpleallocator/Kconfig |  10 ++
>>  drivers/simpleallocator/Makefile|   1 +
>>  drivers/simpleallocator/simple-allocator-priv.h |  33 +
>>  drivers/simpleallocator/simple-allocator.c  | 180 +
>>  include/uapi/linux/simple-allocator.h   |  35 +
>>  8 files changed, 343 insertions(+)
>>  create mode 100644 Documentation/simple-allocator.txt
>>  create mode 100644 drivers/simpleallocator/Kconfig
>>  create mode 100644 drivers/simpleallocator/Makefile
>>  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>>  create mode 100644 drivers/simpleallocator/simple-allocator.c
>>  create mode 100644 include/uapi/linux/simple-allocator.h
>>
>> diff --git a/Documentation/simple-allocator.txt
>> b/Documentation/simple-allocator.txt new file mode 100644
>> index 000..89ba883
>> --- /dev/null
>> +++ b/Documentation/simple-allocator.txt
>> @@ -0,0 +1,81 @@
>> +Simple Allocator Framework
>
> There's nothing simple in buffer allocation, otherwise we would have solved
> the problem a long time ago. Let's not use a misleading name.

Simple was not about the problem, it was about the using only one ioctl.
Anyway a better name is needed: "Limited allocation API", "Basic
allocator framework" ?
suggestions are welcomes

>
>> +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
>> +on dedicated memory regions and export them as a dmabuf file descriptor.
>> +Using dmabuf file descriptor allow to share this memory between processes
>> +and/or import it into other frameworks like v4l2 or drm/kms (prime).
>> +When userland wants to free the memory only a call to close() in needed
>> +so it could done even without knowing that buffer has been allocated by
>> +simple allocator ioctl.
>> +
>> +Each memory regions will be seen as a filein /dev/.
>> +For example CMA regions will exposed has /dev/cmaX.
>
> Why do you need multiple devices ? Furthermore, given how central this API
> will become, I believe it needs very strict review, and would be a candidate
> for a syscall.

I believe that having a device per memory regions is simple than have having,
like ION, heaps which request to add masks (or heap ids) to select them.
My goal here is not to have a a central device /dev/simple_allocator
where allcoations
are dispatched over heaps but only a common ioctl to make userland life easier.
Maybe I should regroup all the device under the same directory: /dev/simple/ ?

>
> Without diving into details yet, there are a few particular points I'm
> concerned about.
>
> - What is the scope of this API ? What problems do you want to solve, plan to
> solve in the future, and consider as out of scope ?

My problem is to be able to allocate a buffer in contiguous memory
(CMA) when using
a software decoder and Weston. This will save the copy between decoder
and display
because display only accepted contiguous memory.
Wayland dmabuf protocol can't allocate buffers so I need an other way
to get access to CMA.
I also other use cases where I need to allocate memory in special
memory region for secure
purpose.

For those both cases I need an API to allocate memory from userland so
I decided to
propose a common ioctl which may be used for even more memory regions.

>
> - How should we handle permissions and resource limits ? Is file-based
> permission on a device node a good model ? How do we prevent or at least
> mitigate memory-related DoS ?

Since each memory region will be represented by a device we could set per
device permissions for example with SELinux policy.

>
> - How should such a central allocator API interact with containers and
> virtualization in general ?

I'm not expert enough in container and virtualization but I know they could have
access to some files/directories to store data so I guess it will
possible for them
to call (for example) /dev/cma0  to allocate memory

> - What model do we want to expose to applications to select a memory type ?
> You still haven't convinced me that we should expose memory pools explicitly
> to application (à la ION), and I believe a usage/constraint model would be
> better.

Memory type selection should be solved by something more smarter than my code.
My goal here is only to provided a common way to perform allocations.
If  "Unix Device Memory 

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Laurent Pinchart]

Hi Daniel,

On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:
> On Tue, Feb 14, 2017 at 8:39 PM, Laurent Pinchart wrote:
> > On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
> >> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
> >>> This is the core of simple allocator module.
> >>> It aim to offert one common ioctl to allocate specific memory.
> >>> 
> >>> version 2:
> >>> - rebased on 4.10-rc7
> >>> 
> >>> Signed-off-by: Benjamin Gaignard 
> >> 
> >> Why not ION? It's a bit a broken record question, but if there is a
> >> clear answer it should be in the patch ...
> > 
> > There's a bit of love & hate relationship between Linux developers and
> > ION. The API has shortcomings, and attempts to fix the issues went
> > nowhere. As Laura explained, starting from a blank slate (obviously
> > keeping in mind the lessons learnt so far with ION and other similar APIs)
> > and then adding a wrapper to expose ION on Android systems (at least as an
> > interim measure) was thought to be a better option. I still believe it is,
> > but we seem to lack traction. The problem has been around for so long that
> > I feel everybody has lost hope.
> > 
> > I don't think this is unsolvable, but we need to regain motivation. In my
> > opinion the first step would be to define the precise extent of the
> > problem we want to solve.
> 
> I'm not sure anyone really tried hard enough (in the same way no one
> tried hard enough to destage android syncpts, until last year). And
> anything new should at least very clearly explain why ION (even with
> the various todo items we collected at a few conferences) won't work,
> and how exactly the new allocator is different from ION. I don't think
> we need a full design doc (like you say, buffer allocation is hard,
> we'll get it wrong anyway), but at least a proper comparison with the
> existing thing. Plus explanation why we can't reuse the uabi.

I've explained several of my concerns (including open questions that need 
answers) in another reply to this patch, let's discuss them there to avoid 
splitting the discussion.

> Because ime when you rewrite something, you generally get one thing
> right (the one thing that pissed you off about the old solution), plus
> lots and lots of things that the old solution got right, wrong
> (because it's all lost in the history).

History, repeating mistakes, all that. History never repeats itself though. We 
might make similar or identical mistakes, but there's no fatality, unless we 
decide not to try before even starting :-)

> ADF was probably the best example in this. KMS also took a while until all
> the fbdev wheels have been properly reinvented (some are still the same old
> squeaky onces as fbdev had, e.g. fbcon).
> 
> And I don't think destaging ION is going to be hard, just a bit of
> work (could be a nice gsoc or whatever).

Oh, technically speaking, it would be pretty simple. The main issue is to 
decide whether we want to commit to the existing ION API. I don't :-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Daniel Vetter]

On Tue, Feb 14, 2017 at 8:39 PM, Laurent Pinchart
 wrote:
> Hi Daniel,
>
> On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
>> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
>> > This is the core of simple allocator module.
>> > It aim to offert one common ioctl to allocate specific memory.
>> >
>> > version 2:
>> > - rebased on 4.10-rc7
>> >
>> > Signed-off-by: Benjamin Gaignard 
>>
>> Why not ION? It's a bit a broken record question, but if there is a
>> clear answer it should be in the patch ...
>
> There's a bit of love & hate relationship between Linux developers and ION.
> The API has shortcomings, and attempts to fix the issues went nowhere. As
> Laura explained, starting from a blank slate (obviously keeping in mind the
> lessons learnt so far with ION and other similar APIs) and then adding a
> wrapper to expose ION on Android systems (at least as an interim measure) was
> thought to be a better option. I still believe it is, but we seem to lack
> traction. The problem has been around for so long that I feel everybody has
> lost hope.
>
> I don't think this is unsolvable, but we need to regain motivation. In my
> opinion the first step would be to define the precise extent of the problem we
> want to solve.

I'm not sure anyone really tried hard enough (in the same way no one
tried hard enough to destage android syncpts, until last year). And
anything new should at least very clearly explain why ION (even with
the various todo items we collected at a few conferences) won't work,
and how exactly the new allocator is different from ION. I don't think
we need a full design doc (like you say, buffer allocation is hard,
we'll get it wrong anyway), but at least a proper comparison with the
existing thing. Plus explanation why we can't reuse the uabi.

Because ime when you rewrite something, you generally get one thing
right (the one thing that pissed you off about the old solution), plus
lots and lots of things that the old solution got right, wrong
(because it's all lost in the history). ADF was probably the best
example in this. KMS also took a while until all the fbdev wheels have
been properly reinvented (some are still the same old squeaky onces as
fbdev had, e.g. fbcon).

And I don't think destaging ION is going to be hard, just a bit of
work (could be a nice gsoc or whatever).
-Daniel

>
>> > ---
>> >
>> >  Documentation/simple-allocator.txt  |  81 +++
>> >  drivers/Kconfig |   2 +
>> >  drivers/Makefile|   1 +
>> >  drivers/simpleallocator/Kconfig |  10 ++
>> >  drivers/simpleallocator/Makefile|   1 +
>> >  drivers/simpleallocator/simple-allocator-priv.h |  33 +
>> >  drivers/simpleallocator/simple-allocator.c  | 180 +++
>> >  include/uapi/linux/simple-allocator.h   |  35 +
>> >  8 files changed, 343 insertions(+)
>> >  create mode 100644 Documentation/simple-allocator.txt
>> >  create mode 100644 drivers/simpleallocator/Kconfig
>> >  create mode 100644 drivers/simpleallocator/Makefile
>> >  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>> >  create mode 100644 drivers/simpleallocator/simple-allocator.c
>> >  create mode 100644 include/uapi/linux/simple-allocator.h
>> >
>> > diff --git a/Documentation/simple-allocator.txt
>> > b/Documentation/simple-allocator.txt new file mode 100644
>> > index 000..89ba883
>> > --- /dev/null
>> > +++ b/Documentation/simple-allocator.txt
>> > @@ -0,0 +1,81 @@
>> > +Simple Allocator Framework
>> > +
>> > +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
>> > +on dedicated memory regions and export them as a dmabuf file descriptor.
>> > +Using dmabuf file descriptor allow to share this memory between processes
>> > +and/or import it into other frameworks like v4l2 or drm/kms (prime).
>> > +When userland wants to free the memory only a call to close() in needed
>> > +so it could done even without knowing that buffer has been allocated by
>> > +simple allocator ioctl.
>> > +
>> > +Each memory regions will be seen as a filein /dev/.
>> > +For example CMA regions will exposed has /dev/cmaX.
>> > +
>> > +Implementing a simple allocator
>> > +---
>> > +
>> > +Simple Allocator provide helpers functions to register/unregister an
>> > +allocator:
>> > +- simple_allocator_register(struct sa_device *sadev)
>> > +  Register simple_allocator_device using sa_device structure where name,
>> > +  owner and allocate fields must be set.
>> > +
>> > +- simple_allocator_unregister(struct sa_device *sadev)
>> > +  Unregister a simple allocator device.
>> > +
>> > +Using Simple Allocator /dev interface example
>> > +-
>> > +
>> > +This example of code allocate a buffer on the first CMA region
>> > (/dev/cma0)
>> > +before mmap and close it.

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Laurent Pinchart]

Hi Daniel,

On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
> > This is the core of simple allocator module.
> > It aim to offert one common ioctl to allocate specific memory.
> > 
> > version 2:
> > - rebased on 4.10-rc7
> > 
> > Signed-off-by: Benjamin Gaignard 
> 
> Why not ION? It's a bit a broken record question, but if there is a
> clear answer it should be in the patch ...

There's a bit of love & hate relationship between Linux developers and ION. 
The API has shortcomings, and attempts to fix the issues went nowhere. As 
Laura explained, starting from a blank slate (obviously keeping in mind the 
lessons learnt so far with ION and other similar APIs) and then adding a 
wrapper to expose ION on Android systems (at least as an interim measure) was 
thought to be a better option. I still believe it is, but we seem to lack 
traction. The problem has been around for so long that I feel everybody has 
lost hope.

I don't think this is unsolvable, but we need to regain motivation. In my 
opinion the first step would be to define the precise extent of the problem we 
want to solve.

> > ---
> > 
> >  Documentation/simple-allocator.txt  |  81 +++
> >  drivers/Kconfig |   2 +
> >  drivers/Makefile|   1 +
> >  drivers/simpleallocator/Kconfig |  10 ++
> >  drivers/simpleallocator/Makefile|   1 +
> >  drivers/simpleallocator/simple-allocator-priv.h |  33 +
> >  drivers/simpleallocator/simple-allocator.c  | 180 +++
> >  include/uapi/linux/simple-allocator.h   |  35 +
> >  8 files changed, 343 insertions(+)
> >  create mode 100644 Documentation/simple-allocator.txt
> >  create mode 100644 drivers/simpleallocator/Kconfig
> >  create mode 100644 drivers/simpleallocator/Makefile
> >  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
> >  create mode 100644 drivers/simpleallocator/simple-allocator.c
> >  create mode 100644 include/uapi/linux/simple-allocator.h
> > 
> > diff --git a/Documentation/simple-allocator.txt
> > b/Documentation/simple-allocator.txt new file mode 100644
> > index 000..89ba883
> > --- /dev/null
> > +++ b/Documentation/simple-allocator.txt
> > @@ -0,0 +1,81 @@
> > +Simple Allocator Framework
> > +
> > +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
> > +on dedicated memory regions and export them as a dmabuf file descriptor.
> > +Using dmabuf file descriptor allow to share this memory between processes
> > +and/or import it into other frameworks like v4l2 or drm/kms (prime).
> > +When userland wants to free the memory only a call to close() in needed
> > +so it could done even without knowing that buffer has been allocated by
> > +simple allocator ioctl.
> > +
> > +Each memory regions will be seen as a filein /dev/.
> > +For example CMA regions will exposed has /dev/cmaX.
> > +
> > +Implementing a simple allocator
> > +---
> > +
> > +Simple Allocator provide helpers functions to register/unregister an
> > +allocator:
> > +- simple_allocator_register(struct sa_device *sadev)
> > +  Register simple_allocator_device using sa_device structure where name,
> > +  owner and allocate fields must be set.
> > +
> > +- simple_allocator_unregister(struct sa_device *sadev)
> > +  Unregister a simple allocator device.
> > +
> > +Using Simple Allocator /dev interface example
> > +-
> > +
> > +This example of code allocate a buffer on the first CMA region
> > (/dev/cma0)
> > +before mmap and close it.
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "simple-allocator.h"
> > +
> > +#define LENGTH 1024*16
> > +
> > +void main (void)
> > +{
> > +   struct simple_allocate_data data;
> > +   int fd = open("/dev/cma0", O_RDWR, 0);
> > +   int ret;
> > +   void *mem;
> > +
> > +   if (fd < 0) {
> > +   printf("Can't open /dev/cma0\n");
> > +   return;
> > +   }
> > +
> > +   memset(, 0, sizeof(data));
> > +
> > +   data.length = LENGTH;
> > +   data.flags = O_RDWR | O_CLOEXEC;
> > +
> > +   ret = ioctl(fd, SA_IOC_ALLOC, );
> > +   if (ret) {
> > +   printf("Buffer allocation failed\n");
> > +   goto end;
> > +   }
> > +
> > +   mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd,
> > 0); +   if (mem == MAP_FAILED) {
> > +   printf("mmap failed\n");
> > +   }
> > +
> > +   memset(mem, 0xFF, LENGTH);
> > +   munmap(mem, LENGTH);
> > +
> > +   printf("test simple allocator CMA OK\n");
> > +end:
> > +   close(fd);
> > +}
> > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > index 

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Daniel Vetter]

On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard
 wrote:
> This is the core of simple allocator module.
> It aim to offert one common ioctl to allocate specific memory.
>
> version 2:
> - rebased on 4.10-rc7
>
> Signed-off-by: Benjamin Gaignard 

Why not ION? It's a bit a broken record question, but if there is a
clear answer it should be in the patch ...
-Daniel

> ---
>  Documentation/simple-allocator.txt  |  81 +++
>  drivers/Kconfig |   2 +
>  drivers/Makefile|   1 +
>  drivers/simpleallocator/Kconfig |  10 ++
>  drivers/simpleallocator/Makefile|   1 +
>  drivers/simpleallocator/simple-allocator-priv.h |  33 +
>  drivers/simpleallocator/simple-allocator.c  | 180 
> 
>  include/uapi/linux/simple-allocator.h   |  35 +
>  8 files changed, 343 insertions(+)
>  create mode 100644 Documentation/simple-allocator.txt
>  create mode 100644 drivers/simpleallocator/Kconfig
>  create mode 100644 drivers/simpleallocator/Makefile
>  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>  create mode 100644 drivers/simpleallocator/simple-allocator.c
>  create mode 100644 include/uapi/linux/simple-allocator.h
>
> diff --git a/Documentation/simple-allocator.txt 
> b/Documentation/simple-allocator.txt
> new file mode 100644
> index 000..89ba883
> --- /dev/null
> +++ b/Documentation/simple-allocator.txt
> @@ -0,0 +1,81 @@
> +Simple Allocator Framework
> +
> +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
> +on dedicated memory regions and export them as a dmabuf file descriptor.
> +Using dmabuf file descriptor allow to share this memory between processes
> +and/or import it into other frameworks like v4l2 or drm/kms (prime).
> +When userland wants to free the memory only a call to close() in needed
> +so it could done even without knowing that buffer has been allocated by
> +simple allocator ioctl.
> +
> +Each memory regions will be seen as a filein /dev/.
> +For example CMA regions will exposed has /dev/cmaX.
> +
> +Implementing a simple allocator
> +---
> +
> +Simple Allocator provide helpers functions to register/unregister an
> +allocator:
> +- simple_allocator_register(struct sa_device *sadev)
> +  Register simple_allocator_device using sa_device structure where name,
> +  owner and allocate fields must be set.
> +
> +- simple_allocator_unregister(struct sa_device *sadev)
> +  Unregister a simple allocator device.
> +
> +Using Simple Allocator /dev interface example
> +-
> +
> +This example of code allocate a buffer on the first CMA region (/dev/cma0)
> +before mmap and close it.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "simple-allocator.h"
> +
> +#define LENGTH 1024*16
> +
> +void main (void)
> +{
> +   struct simple_allocate_data data;
> +   int fd = open("/dev/cma0", O_RDWR, 0);
> +   int ret;
> +   void *mem;
> +
> +   if (fd < 0) {
> +   printf("Can't open /dev/cma0\n");
> +   return;
> +   }
> +
> +   memset(, 0, sizeof(data));
> +
> +   data.length = LENGTH;
> +   data.flags = O_RDWR | O_CLOEXEC;
> +
> +   ret = ioctl(fd, SA_IOC_ALLOC, );
> +   if (ret) {
> +   printf("Buffer allocation failed\n");
> +   goto end;
> +   }
> +
> +   mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
> +   if (mem == MAP_FAILED) {
> +   printf("mmap failed\n");
> +   }
> +
> +   memset(mem, 0xFF, LENGTH);
> +   munmap(mem, LENGTH);
> +
> +   printf("test simple allocator CMA OK\n");
> +end:
> +   close(fd);
> +}
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index e1e2066..a6d8828 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> @@ -202,4 +202,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>
>  source "drivers/fpga/Kconfig"
>
> +source "drivers/simpleallocator/Kconfig"
> +
>  endmenu
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 060026a..5081eb8 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -173,3 +173,4 @@ obj-$(CONFIG_STM)   += hwtracing/stm/
>  obj-$(CONFIG_ANDROID)  += android/
>  obj-$(CONFIG_NVMEM)+= nvmem/
>  obj-$(CONFIG_FPGA) += fpga/
> +obj-$(CONFIG_SIMPLE_ALLOCATOR) += simpleallocator/
> diff --git a/drivers/simpleallocator/Kconfig b/drivers/simpleallocator/Kconfig
> new file mode 100644
> index 000..c6fc2e3
> --- /dev/null
> +++ b/drivers/simpleallocator/Kconfig
> @@ -0,0 +1,10 @@
> +menu "Simple Allocator"
> +
> +config SIMPLE_ALLOCATOR
> +   tristate "Simple Alllocator Framework"
> +   select DMA_SHARED_BUFFER
> +   

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

[Laurent Pinchart]

Hi Benjamin,

Thank you for the patch. I've CC'ed the linux-api mailing list.

On Monday 13 Feb 2017 15:45:05 Benjamin Gaignard wrote:
> This is the core of simple allocator module.
> It aim to offert one common ioctl to allocate specific memory.
> 
> version 2:
> - rebased on 4.10-rc7
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  Documentation/simple-allocator.txt  |  81 +++
>  drivers/Kconfig |   2 +
>  drivers/Makefile|   1 +
>  drivers/simpleallocator/Kconfig |  10 ++
>  drivers/simpleallocator/Makefile|   1 +
>  drivers/simpleallocator/simple-allocator-priv.h |  33 +
>  drivers/simpleallocator/simple-allocator.c  | 180 +
>  include/uapi/linux/simple-allocator.h   |  35 +
>  8 files changed, 343 insertions(+)
>  create mode 100644 Documentation/simple-allocator.txt
>  create mode 100644 drivers/simpleallocator/Kconfig
>  create mode 100644 drivers/simpleallocator/Makefile
>  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>  create mode 100644 drivers/simpleallocator/simple-allocator.c
>  create mode 100644 include/uapi/linux/simple-allocator.h
> 
> diff --git a/Documentation/simple-allocator.txt
> b/Documentation/simple-allocator.txt new file mode 100644
> index 000..89ba883
> --- /dev/null
> +++ b/Documentation/simple-allocator.txt
> @@ -0,0 +1,81 @@
> +Simple Allocator Framework

There's nothing simple in buffer allocation, otherwise we would have solved 
the problem a long time ago. Let's not use a misleading name.

> +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
> +on dedicated memory regions and export them as a dmabuf file descriptor.
> +Using dmabuf file descriptor allow to share this memory between processes
> +and/or import it into other frameworks like v4l2 or drm/kms (prime).
> +When userland wants to free the memory only a call to close() in needed
> +so it could done even without knowing that buffer has been allocated by
> +simple allocator ioctl.
> +
> +Each memory regions will be seen as a filein /dev/.
> +For example CMA regions will exposed has /dev/cmaX.

Why do you need multiple devices ? Furthermore, given how central this API 
will become, I believe it needs very strict review, and would be a candidate 
for a syscall.

Without diving into details yet, there are a few particular points I'm 
concerned about.

- What is the scope of this API ? What problems do you want to solve, plan to 
solve in the future, and consider as out of scope ?

- How should we handle permissions and resource limits ? Is file-based 
permission on a device node a good model ? How do we prevent or at least 
mitigate memory-related DoS ?

- How should such a central allocator API interact with containers and 
virtualization in general ?

- What model do we want to expose to applications to select a memory type ? 
You still haven't convinced me that we should expose memory pools explicitly 
to application (à la ION), and I believe a usage/constraint model would be 
better.

> +Implementing a simple allocator
> +---
> +
> +Simple Allocator provide helpers functions to register/unregister an
> +allocator:
> +- simple_allocator_register(struct sa_device *sadev)
> +  Register simple_allocator_device using sa_device structure where name,
> +  owner and allocate fields must be set.
> +
> +- simple_allocator_unregister(struct sa_device *sadev)
> +  Unregister a simple allocator device.
> +
> +Using Simple Allocator /dev interface example
> +-
> +
> +This example of code allocate a buffer on the first CMA region (/dev/cma0)
> +before mmap and close it.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "simple-allocator.h"
> +
> +#define LENGTH 1024*16
> +
> +void main (void)
> +{
> + struct simple_allocate_data data;
> + int fd = open("/dev/cma0", O_RDWR, 0);
> + int ret;
> + void *mem;
> +
> + if (fd < 0) {
> + printf("Can't open /dev/cma0\n");
> + return;
> + }
> +
> + memset(, 0, sizeof(data));
> +
> + data.length = LENGTH;
> + data.flags = O_RDWR | O_CLOEXEC;
> +
> + ret = ioctl(fd, SA_IOC_ALLOC, );
> + if (ret) {
> + printf("Buffer allocation failed\n");
> + goto end;
> + }
> +
> + mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
> + if (mem == MAP_FAILED) {
> + printf("mmap failed\n");
> + }
> +
> + memset(mem, 0xFF, LENGTH);
> + munmap(mem, LENGTH);
> +
> + printf("test simple allocator CMA OK\n");
> +end:
> + close(fd);
> +}
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> index e1e2066..a6d8828 100644
> --- a/drivers/Kconfig
> +++ b/drivers/Kconfig
> 

[RFC simple allocator v2 1/2] Create Simple Allocator module

[Benjamin Gaignard]

This is the core of simple allocator module.
It aim to offert one common ioctl to allocate specific memory.

version 2:
- rebased on 4.10-rc7

Signed-off-by: Benjamin Gaignard 
---
 Documentation/simple-allocator.txt  |  81 +++
 drivers/Kconfig |   2 +
 drivers/Makefile|   1 +
 drivers/simpleallocator/Kconfig |  10 ++
 drivers/simpleallocator/Makefile|   1 +
 drivers/simpleallocator/simple-allocator-priv.h |  33 +
 drivers/simpleallocator/simple-allocator.c  | 180 
 include/uapi/linux/simple-allocator.h   |  35 +
 8 files changed, 343 insertions(+)
 create mode 100644 Documentation/simple-allocator.txt
 create mode 100644 drivers/simpleallocator/Kconfig
 create mode 100644 drivers/simpleallocator/Makefile
 create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
 create mode 100644 drivers/simpleallocator/simple-allocator.c
 create mode 100644 include/uapi/linux/simple-allocator.h

diff --git a/Documentation/simple-allocator.txt 
b/Documentation/simple-allocator.txt
new file mode 100644
index 000..89ba883
--- /dev/null
+++ b/Documentation/simple-allocator.txt
@@ -0,0 +1,81 @@
+Simple Allocator Framework
+
+Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
+on dedicated memory regions and export them as a dmabuf file descriptor.
+Using dmabuf file descriptor allow to share this memory between processes
+and/or import it into other frameworks like v4l2 or drm/kms (prime).
+When userland wants to free the memory only a call to close() in needed
+so it could done even without knowing that buffer has been allocated by
+simple allocator ioctl.
+
+Each memory regions will be seen as a filein /dev/.
+For example CMA regions will exposed has /dev/cmaX.
+
+Implementing a simple allocator
+---
+
+Simple Allocator provide helpers functions to register/unregister an
+allocator:
+- simple_allocator_register(struct sa_device *sadev)
+  Register simple_allocator_device using sa_device structure where name,
+  owner and allocate fields must be set.
+
+- simple_allocator_unregister(struct sa_device *sadev)
+  Unregister a simple allocator device.
+
+Using Simple Allocator /dev interface example
+-
+
+This example of code allocate a buffer on the first CMA region (/dev/cma0)
+before mmap and close it.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "simple-allocator.h"
+
+#define LENGTH 1024*16
+
+void main (void)
+{
+   struct simple_allocate_data data;
+   int fd = open("/dev/cma0", O_RDWR, 0);
+   int ret;
+   void *mem;
+
+   if (fd < 0) {
+   printf("Can't open /dev/cma0\n");
+   return;
+   }
+
+   memset(, 0, sizeof(data));
+
+   data.length = LENGTH;
+   data.flags = O_RDWR | O_CLOEXEC;
+
+   ret = ioctl(fd, SA_IOC_ALLOC, );
+   if (ret) {
+   printf("Buffer allocation failed\n");
+   goto end;
+   }
+
+   mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
+   if (mem == MAP_FAILED) {
+   printf("mmap failed\n");
+   }
+
+   memset(mem, 0xFF, LENGTH);
+   munmap(mem, LENGTH);
+
+   printf("test simple allocator CMA OK\n");
+end:
+   close(fd);
+}
diff --git a/drivers/Kconfig b/drivers/Kconfig
index e1e2066..a6d8828 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -202,4 +202,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
 
 source "drivers/fpga/Kconfig"
 
+source "drivers/simpleallocator/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 060026a..5081eb8 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -173,3 +173,4 @@ obj-$(CONFIG_STM)   += hwtracing/stm/
 obj-$(CONFIG_ANDROID)  += android/
 obj-$(CONFIG_NVMEM)+= nvmem/
 obj-$(CONFIG_FPGA) += fpga/
+obj-$(CONFIG_SIMPLE_ALLOCATOR) += simpleallocator/
diff --git a/drivers/simpleallocator/Kconfig b/drivers/simpleallocator/Kconfig
new file mode 100644
index 000..c6fc2e3
--- /dev/null
+++ b/drivers/simpleallocator/Kconfig
@@ -0,0 +1,10 @@
+menu "Simple Allocator"
+
+config SIMPLE_ALLOCATOR
+   tristate "Simple Alllocator Framework"
+   select DMA_SHARED_BUFFER
+   ---help---
+  The Simple Allocator Framework adds an API to allocate and share
+  memory in userland.
+
+endmenu
diff --git a/drivers/simpleallocator/Makefile b/drivers/simpleallocator/Makefile
new file mode 100644
index 000..e27c6ad
--- /dev/null
+++ b/drivers/simpleallocator/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SIMPLE_ALLOCATOR) += simple-allocator.o
diff --git a/drivers/simpleallocator/simple-allocator-priv.h 
b/drivers/simpleallocator/simple-allocator-priv.h
new file