From: Dan Williams <dan.j.williams@intel.com>
To: <ksummit@lists.linux.dev>
Subject: [MAINTAINERS SUMMIT] Between a rock and a hard place, managing expectations...
Date: Mon, 21 Aug 2023 17:43:21 -0700 [thread overview]
Message-ID: <64e404a979f54_4c1f3294d3@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
This topic shares some aspects with other proposals around maintainer /
contributor stress management, but with a particular focus on current
hardware enabling dynamics.
The observation is that silicon complexity continues an inexorable climb
as functional and performance enhancements literally push the boundaries
our current kernel-user API contracts. Proposals like "offload this to
hardware...", "route that security concern through this mechanism...",
"migrate that application to this resource..." are increasingly less
isolated to self-contained drivers and more likely to have
cross-subsystem implications.
Standardization helps, but there is often a "system-software
implementation-specific" gap that a standard leaves for an operating
system to resolve. Linux is nowadays a first mover, and a primary
deployment target. In that role it is unable to benefit from other
operating system vendors to close that implementation-specific gap and
put a bounding box around hardware vendor differentiation. As always the
only tool Linux has at its disposal to manage those concerns is upstream
code acceptance.
When expectations are mishandled a contributor can find themselves
squeezed between program management and upstream maintainer skepticism.
That friction burns community resources in multiple directions. It is
also a false choice. A contributor's role is to partner with the
maintainer and other hardware vendors of similar functionality to arrive
at a solution that maximizes maintainability. Schedule is important, but
second to maintainability / cross-vendor-scalability.
I perceive a trap where upstream design decisions start to bias towards
expediency rather than maintainability. The theme of the discussion for
maintainer summit is questions like, but not limited to:
- When do vendors need to share a common ABI?
- How well is our "community consensus" protocol working to give
contributors actionable feedback?
- Is there more we can do to enable contributors to steer the right path
out of the expediency vs maintainability trap?
"Confidential Computing" is an example of an area with several
cross-silicon-vendor implementations that continue to add features with
a steady stream of upstream design decisions that cross multiple
subsystems.
next reply other threads:[~2023-08-22 0:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-22 0:43 Dan Williams [this message]
2023-08-22 8:55 ` [MAINTAINERS SUMMIT] Between a rock and a hard place, managing expectations Greg KH
2023-08-22 13:37 ` Linus Walleij
2023-08-22 14:29 ` Laurent Pinchart
2023-08-24 0:46 ` Jason Gunthorpe
2023-08-24 8:16 ` Linus Walleij
2023-08-24 14:19 ` Jason Gunthorpe
2023-08-24 17:12 ` Mark Brown
2023-08-24 17:20 ` Bird, Tim
2023-08-24 19:29 ` Bart Van Assche
2023-08-24 19:58 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64e404a979f54_4c1f3294d3@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=ksummit@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).