Re: Potential topics for the 2021 Maintainer's Summit

[Greg KH <greg@kroah.com>]

On Thu, Sep 23, 2021 at 12:49:25PM +0300, Laurent Pinchart wrote:
> Hi Ted,
> 
> 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 :)

thanks,

greg k-h