* Potential topics for the 2021 Maintainer's Summit
@ 2021-09-23 5:18 Theodore Ts'o
2021-09-23 9:49 ` Laurent Pinchart
2021-09-23 11:10 ` Greg KH
0 siblings, 2 replies; 5+ messages in thread
From: Theodore Ts'o @ 2021-09-23 5:18 UTC (permalink / raw)
To: ksummit
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Potential topics for the 2021 Maintainer's Summit
2021-09-23 5:18 Potential topics for the 2021 Maintainer's Summit Theodore Ts'o
@ 2021-09-23 9:49 ` Laurent Pinchart
2021-09-23 11:09 ` Greg KH
2021-09-23 11:10 ` Greg KH
1 sibling, 1 reply; 5+ messages in thread
From: Laurent Pinchart @ 2021-09-23 9:49 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: ksummit
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Potential topics for the 2021 Maintainer's Summit
2021-09-23 9:49 ` Laurent Pinchart
@ 2021-09-23 11:09 ` Greg KH
2021-09-23 11:32 ` Laurent Pinchart
0 siblings, 1 reply; 5+ messages in thread
From: Greg KH @ 2021-09-23 11:09 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Theodore Ts'o, ksummit
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Potential topics for the 2021 Maintainer's Summit
2021-09-23 11:09 ` Greg KH
@ 2021-09-23 11:32 ` Laurent Pinchart
0 siblings, 0 replies; 5+ messages in thread
From: Laurent Pinchart @ 2021-09-23 11:32 UTC (permalink / raw)
To: Greg KH; +Cc: Theodore Ts'o, ksummit
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Potential topics for the 2021 Maintainer's Summit
2021-09-23 5:18 Potential topics for the 2021 Maintainer's Summit Theodore Ts'o
2021-09-23 9:49 ` Laurent Pinchart
@ 2021-09-23 11:10 ` Greg KH
1 sibling, 0 replies; 5+ messages in thread
From: Greg KH @ 2021-09-23 11:10 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: ksummit
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-09-23 11:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-23 5:18 Potential topics for the 2021 Maintainer's Summit Theodore Ts'o
2021-09-23 9:49 ` Laurent Pinchart
2021-09-23 11:09 ` Greg KH
2021-09-23 11:32 ` Laurent Pinchart
2021-09-23 11:10 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).