Re: RFC: CCC Linux Kernel SIG

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2023-11-07 at 19:24 -0600, Dan Middleton wrote:
> One of the technical limitations to the adoption rate for
> Confidential Computing is the speed at which we as a community can
> add features to the Linux kernel. Each vendor has similar needs of
> the kernel but has historically presented significantly different
> ABIs. To  contain complexity and manage maintainability, the Linux
> kernel community tries to prevent proliferation of unnecessarily
> vendor specific ABIs. Often the opportunity for commonality is
> unclear until multiple vendors have proposed separate interfaces [0].

The kernel community would see this as a feature not a bug.  It's very
difficult to appreciate the technical ramifications until you see the
actual code so even though it seems like more work in the beginning it
produces better and faster outcomes in the end.

To give the counter point to your example: each CC implementation had
its own ioctl set.  The proposal unifies it through a configfs
interface, but it's still not clear that the unification covers all the
use cases.  This, though, can be worked through after the acceptance of
the configfs pull request.  Adding ioctls is fairly simple, so there
wasn't really much wasted work before agreement was reached on a
preliminary design for configfs which can now be worked on by everyone.

[...]
> The Linux kernel community has not been a regular part of 
> discussions and the CCC has not been a regular participant on the
> Linux Kernel Mail List (LKML)[1].

Isn't this the current key problem with an obvious solution: the
interested members of the CCC can simply join the lists.  You could
make them do a formalised readout back to the CCC for people who don't
want to be at the kernel list sharp end and establish an action plan
from there if things are perceived to be going wrong.

> The pipeline of activity is expected (but not required) to look like
> this:
> 1. Identify feature need on mailing list or informal forum.
> 2. Exchange community proposals in the SIG.
> 3. Achieve informal consensus in the SIG.
> 
>      a. Author patches and take them to the appropriate community,
> e.g., LKML.

This really isn't the correct workflow for the Kernel.  The kernel
likes to see sketches in code when arguing about ABI and design.

The process really already works like your 1,2,3 with the exception
that 1. begins on the kernel or KVM list.  Trying to achieve consensus
in some other industrial forum and then present the patches to the list
as the unified consensus hasn't really worked out well in the past
(NVMe still has the scars to prove this).

[...]
> In addition to video meetings, the community will use an existing 
> Discord channel for ongoing communication

Just on a personal note: I've had no end of trouble with Discord,
primarily around the verification requirements for my email address
preventing me from getting an account from the single gatekeeper, so it
would be last on my list of useful systems for open conversations.

James