Potential topics for the 2021 Maintainer's Summit

Potential topics for the 2021 Maintainer's Summit

[Theodore Ts'o]

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?

* Acceptance criteria of patch sets
    The discussion over the folio patch set seems to be making forward
    progress, but it's not the only case where we've had some disagreements
    over large code contribuions: ntfs3 and ksmbd come to mind.
    Also from the kernel summit, see slide 10 ("Upstreaming Agony) at: 
    https://linuxplumbersconf.org/event/11/contributions/964/attachments/802/1511/Ksummit%20%283%29.pdf

    "We want to upstream everything. It makes Linux better and our lives easier.
    However:
    * High variability in maintainer responsiveness
    	 * Some subsystems are really great
    	 * Some armitecture maintainers are not as easy to work with
    	 * Some subsystems are just stuck (e.g. memory management)
    * Replies often come with “helpful” suggestions of radical product redesign
         * E.g. preempt count passthrough for VMs to improve scheduling of
	   guests
    * Plus usual stuff, e.g. “oh sure we can apply this two liner… *after*
       you rewrite the subsystem”
    Wishlist:
    * Consistent maintainer responsiveness and acceptance criteria
        * A maintainer CoC or expectations doc?
    * More data driven decision making (e.g. which benchmarks are generally
      agreed to be important for each subsystem)
    * More openness to experimentation
        * How can we enable this?"

* Rust in the Kernel
    We could potentially invite Miguel so we can give him feedback, concerns,
    etc. regarding Rust in the kernel.  In particular, Miguel asked
    some questions at the end of his talk at the Kernel Summit:
    https://youtu.be/mF10hgVIx9o?t=15245
    for which feedback from the maintainers might be helpful --- if
    we are ready to give an opinion, which is not clear.

* Is Linus happy/unhappy with the development process of Linux?
    Anything else we need to discuss or address?


Also, this is the current list of invitees to the Maintainer's Summit
(including sponsored attendees).  As we finalize the topics, there may
be one or two additional invites.  (For example, if we do decide to
pursue the Rust in the kernel topic, we would need to invite Miguel,
assuming he would be available on Friday.)

Al Viro
Alex Deucher
Alexei Starovoitov
Andrew Morton
Arnd Bergmann
Bjorn Helgaas
Borislav Petkov
Chris Mason
Christoph Hellwig
Damien Le Moal
Dave Airlie
David S. Miller
Greg Kroah-Hartman
Ingo Molnar
Jakub Kicinski
Jens Axboe
Jon Corbet
Kees Cook
Linus Torvalds
Mark Brown
Martin K. Petersen
Michael Ellerman
Rafael J. Wysocki
Sasha Levin
Stephen Rothwell
Theodore Ts'o
Thomas Gleixner
Vasily Gorbik
Will Deacon

Re: Potential topics for the 2021 Maintainer's Summit

[Laurent Pinchart]

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).

> * Acceptance criteria of patch sets
>     The discussion over the folio patch set seems to be making forward
>     progress, but it's not the only case where we've had some disagreements
>     over large code contribuions: ntfs3 and ksmbd come to mind.
>     Also from the kernel summit, see slide 10 ("Upstreaming Agony) at: 
>     https://linuxplumbersconf.org/event/11/contributions/964/attachments/802/1511/Ksummit%20%283%29.pdf
> 
>     "We want to upstream everything. It makes Linux better and our lives easier.
>     However:
>     * High variability in maintainer responsiveness
>     	 * Some subsystems are really great
>     	 * Some armitecture maintainers are not as easy to work with
>     	 * Some subsystems are just stuck (e.g. memory management)
>     * Replies often come with “helpful” suggestions of radical product redesign
>          * E.g. preempt count passthrough for VMs to improve scheduling of
> 	   guests
>     * Plus usual stuff, e.g. “oh sure we can apply this two liner… *after*
>        you rewrite the subsystem”
>     Wishlist:
>     * Consistent maintainer responsiveness and acceptance criteria
>         * A maintainer CoC or expectations doc?
>     * More data driven decision making (e.g. which benchmarks are generally
>       agreed to be important for each subsystem)
>     * More openness to experimentation
>         * How can we enable this?"
> 
> * Rust in the Kernel
>     We could potentially invite Miguel so we can give him feedback, concerns,
>     etc. regarding Rust in the kernel.  In particular, Miguel asked
>     some questions at the end of his talk at the Kernel Summit:
>     https://youtu.be/mF10hgVIx9o?t=15245
>     for which feedback from the maintainers might be helpful --- if
>     we are ready to give an opinion, which is not clear.
> 
> * Is Linus happy/unhappy with the development process of Linux?
>     Anything else we need to discuss or address?
> 
> 
> Also, this is the current list of invitees to the Maintainer's Summit
> (including sponsored attendees).  As we finalize the topics, there may
> be one or two additional invites.  (For example, if we do decide to
> pursue the Rust in the kernel topic, we would need to invite Miguel,
> assuming he would be available on Friday.)
> 
> Al Viro
> Alex Deucher
> Alexei Starovoitov
> Andrew Morton
> Arnd Bergmann
> Bjorn Helgaas
> Borislav Petkov
> Chris Mason
> Christoph Hellwig
> Damien Le Moal
> Dave Airlie
> David S. Miller
> Greg Kroah-Hartman
> Ingo Molnar
> Jakub Kicinski
> Jens Axboe
> Jon Corbet
> Kees Cook
> Linus Torvalds
> Mark Brown
> Martin K. Petersen
> Michael Ellerman
> Rafael J. Wysocki
> Sasha Levin
> Stephen Rothwell
> Theodore Ts'o
> Thomas Gleixner
> Vasily Gorbik
> Will Deacon

-- 
Regards,

Laurent Pinchart

Re: Potential topics for the 2021 Maintainer's Summit

[Greg KH]

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

Re: Potential topics for the 2021 Maintainer's Summit

[Greg KH]

On Thu, Sep 23, 2021 at 01:18:11AM -0400, Theodore Ts'o wrote:
> 
> 		  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.

That is implying that something _should_ be done differently next time :)

Anyway, sure, I'll be glad to talk about this.

thanks,

greg k-h

Re: Potential topics for the 2021 Maintainer's Summit

[Laurent Pinchart]

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