linux-kernel - Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework

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:   Fri, 15 Mar 2019 14:29:03 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Laura Abbott <labbott@...hat.com>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        "Andrew F. Davis" <afd@...com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Liam Mark <lmark@...eaurora.org>,
        Brian Starkey <Brian.Starkey@....com>,
        Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework

On Fri, Mar 15, 2019 at 1:18 PM Laura Abbott <labbott@...hat.com> wrote:
>
> On 3/5/19 12:54 PM, John Stultz wrote:
> > +DMA-BUF HEAPS FRAMEWORK
> > +M:   Laura Abbott<labbott@...hat.com>
> > +R:   Liam Mark<lmark@...eaurora.org>
> > +R:   Brian Starkey<Brian.Starkey@....com>
> > +R:   "Andrew F. Davis"<afd@...com>
> > +R:   John Stultz<john.stultz@...aro.org>
> > +S:   Maintained
> > +L:   linux-media@...r.kernel.org
> > +L:   dri-devel@...ts.freedesktop.org
> > +L:   linaro-mm-sig@...ts.linaro.org  (moderated for non-subscribers)
> > +F:   include/uapi/linux/dma-heap.h
> > +F:   include/linux/dma-heap.h
> > +F:   drivers/dma-buf/dma-heap.c
> > +F:   drivers/dma-buf/heaps/*
> > +T:   git git://anongit.freedesktop.org/drm/drm-misc
>
> So I talked about this with Sumit privately but I think
> it might make sense to have me step down as maintainer when
> this goes out of staging. I mostly worked on Ion at my
> previous position and anything I do now is mostly a side
> project. I still want to see it succeed which is why I
> took on the maintainer role but I don't want to become blocking
> for people who have a stronger vision about where this needs
> to go (see also, I'm not working with this on a daily basis).
>
> If you just want someone to help review or take patches
> to be pulled, I'm happy to do so but I'd hate to become
> the bottleneck on getting things done for people who
> are attempting to do real work.

I worry this will make everyone to touch the side of their nose and
yell "NOT IT!" :)

First of all, thank you so much for your efforts maintaining ION along
with your attempts to drag out requirements from interested parties
and the numerous attempts to get collaborative discussion going at
countless conferences! Your persistence and continual nudging in the
face of apathetic private users of the code probably cannot be
appreciated enough!

Your past practical experience with ION and active work with the
upstream community made you a stand out pick for this, but I
understand not wanting to be eternally stuck with a maintainership if
your not active in the area.  I'm happy to volunteer as a neutral
party, but I worry my limited experience with some of the more
complicated usage would make my opinions less informed then they
probably need to be.  Further, as a neutral party, Sumit would
probably be a better pick since he's already maintaining the dmabuf
core.

So I'd nominate Andrew, Liam or Benjamin (or all three?) as they all
have more practical experience enabling past ION heaps on real devices
and have demonstrated active interest in working in the community.

So, in other words... NOT IT! :)
-john