Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1581136

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

From Benjamin Gaignard <benjamin.gaignard@linaro.org>
Newsgroups linux.kernel
Subject Re: [RFC simple allocator v2 1/2] Create Simple Allocator module
Date 2017-02-15 10:00 +0100
Message-ID <tb3Bn-678-15@gated-at.bofh.it> (permalink)
References <taq70-4Xt-13@gated-at.bofh.it> <taR7c-5Vy-17@gated-at.bofh.it> <taRgR-5Z8-15@gated-at.bofh.it> <taRqy-62G-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


2017-02-14 20:59 GMT+01:00 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> 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 <benjamin.gaignard@linaro.org>
>> >>
>> >> Why not ION? It's a bit a broken record question, but if there is a
>> >> clear answer it should be in the patch&docs ...
>> >
>> > 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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC simple allocator v2 1/2] Create Simple Allocator module Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-02-14 20:40 +0100
  Re: [RFC simple allocator v2 1/2] Create Simple Allocator module Daniel Vetter <daniel.vetter@ffwll.ch> - 2017-02-14 20:50 +0100
    Re: [RFC simple allocator v2 1/2] Create Simple Allocator module Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-02-14 21:00 +0100
      Re: [RFC simple allocator v2 1/2] Create Simple Allocator module Benjamin Gaignard <benjamin.gaignard@linaro.org> - 2017-02-15 10:00 +0100
      Re: [RFC simple allocator v2 1/2] Create Simple Allocator module Mark Brown <broonie@kernel.org> - 2017-02-15 13:20 +0100
        Re: [RFC simple allocator v2 1/2] Create Simple Allocator module Daniel Vetter <daniel@ffwll.ch> - 2017-02-26 21:40 +0100

csiph-web