Re: Potential topics for the 2021 Maintainer's Summit

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Greg,

On Thu, Sep 23, 2021 at 01:09:31PM +0200, Greg KH wrote:
> On Thu, Sep 23, 2021 at 12:49:25PM +0300, Laurent Pinchart wrote:
> > On Thu, Sep 23, 2021 at 01:18:11AM -0400, Theodore Ts'o wrote:
> > > 
> > > After discussions amongst the program committee, and looking at some
> > > of the discussions to date at the LPC and the Kernel Summit, we've
> > > come up with the following potential topics for the Maintainer's
> > > Summit.
> > > 
> > > This is not the final agenda.  We are soliciting suggestions and
> > > comments about these topics.  Is there anything we are missing?  Is
> > > there something you think wouldn't be productive for us to discuss?
> > > 
> > > 
> > > 		  Potential Maintainer Summit topics
> > > 
> > > * Reviewing how we reacted to the University of Minnesota issue
> > >     After Greg K-H gives a non-technical summary of what
> > >     happened, and we would have a discussion about what should be
> > >     done differently next time.
> > > 
> > > * User-space requirementrs for accelerator drivers
> > >     There was some good discussion on the ksummit list, but there still isn't
> > >     a clear consensus of what the policy should be.  From Jon's message
> > >     kicking off that thread:
> > > 
> > >     - Under which circumstances should the kernel community require the
> > >       existence of freely licensed user-space code that exercises all
> > >       functionalities of a proposed kernel driver or feature?
> > > 
> > >     - Are there internal kernel interfaces, such as DMA-BUF or P2PDMA, that
> > >       are only available to drivers with a free user-space implementation?
> > >       Do we need an EXPORT_SYMBOL_USERSPACE_GPL()?
> > > 
> > >     - What constitutes an acceptable user-space implementation in cases
> > >       where these restrictions apply?
> > 
> > Just a quick comment on this. if it can be useful information, I'd be
> > happy to briefly explain and answer questions about the ongoing effort
> > to build a camera stack for Linux. We're running into the exact same
> > issues, and have been trying to build bridges with SoC vendors over the
> > past few years (with various levels of success).
> 
> I think there's two different main topics here:
> 	- where to move the existing accelerator drivers to in the tree
> 	  and who should maintain them
> 	- requirements for accepting kernel code that has new
> 	  user/kernel apis
> 
> The first topic doesn't really pertain to v4l and libcamera, but the
> second topic would :)

I'm sure libcamera will use accelerators one day, but for the time
being, you're right :-) The discussion stemmed from accelerators and has
broaden to more types of devices. Depending on the scope of the
discussion at the maintainer's summit, I'll be happy to contribute or
stay away :-)

-- 
Regards,

Laurent Pinchart