Re: [PATCH 0/8] Introduce fwctl subystem

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

>   One of the release valves in the CXL space is openly specified
>   commands with opaque payloads, like "Read Vendor Debug Log". That is
>   clear what it does, likely a payload the kernel need never worry
>   about, and the "Command Effects" is empty. However, going forward there
>   is a new class of commands called "Set/Get Feature" that allow a wide
>   range of vendor toggles to be deployed which will need an upstream
>   response for the driver policy to vendor-specific "Features".

Irrelevant rat hole time ;)

I don't see those Set / Get feature as any different from other commands.
I see them as a convenience mostly there to cut down on spec duplication
and enforce some consistency across multiple similar commands, but they
are just commands like any other, validation is just one step further
into the payload.

There are already a bunch of them in the main CXL spec and like you mention
above if someone brings a well documented vendor feature (or feature from
another standard etc), then if appropriate we could let that through the
filter as well.

Same will be true of tunneled commands (I think we can ignore the cross
host security aspect of those). Ultimately we can sanity check the payload
much like a top level command.

So I mostly agree with rest of what you've said, but think this detail
doesn't matter.

> 
> So if fwctl, or something like it, can strike a balance of enforcing
> integrity and introspection while encouraging collaboration on the
> aspects that are worth upstream collaboration, I think that is a
> conversation worth having.
> 
> [1]: http://lore.kernel.org/r/CAPcyv4gDShAYih5iWabKg_eTHhuHm54vEAei8ZkcmHnPp3B0cw@mail.gmail.com/
> [2]: http://lore.kernel.org/r/20240321174423.00007e0d@Huawei.com
>