2017-02-14 20:59 GMT+01:00 Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>: > 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@xxxxxxxxxx> >> >> >> >> 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
