On Fri, Jul 26, 2024 at 03:49:49PM +0300, Laurent Pinchart wrote:

What is not an option exactly in my description above ? We have multiple
V4L2 drivers for ISPs. They receive ISP parameters from userspace
through a data buffer. It's not allowed to be opaque, but it doesn't
prevent vendor closed-source userspace implementations with additional
*camera* features, as long as the *hardware* features are available to
everybody.

How far do you take opaque?

In mlx5 we pass command buffers from user to kernel to HW and the
kernel does only a little checking.

There is a 12kloc file describing the layout of alot of commands:
include/linux/mlx5/mlx5_ifc.h

There is an open PDF describing in detail some subset of this:
https://network.nvidia.com/files/doc-2020/ethernet-adapters-programming-manual.pdf

There are in-kernel implementations driving most of those commands.

Other commands are only issued by userspace, and we have open source
DPDK, rdma-core and UCX implementations driving them.

ie, this is really quite good as far as a device providing open source
solutions goes.

However, no doubt there is more FW capability and commands than even
this vast amount documents - so lets guess that propritary code is
using this interface with unknown commands too.

From a camera perspective would you be OK with that? Let's guess that
90% of use cases are covered with fully open code. Do we also need to
forcefully close the door to an imagined 10% of proprietary cases just
to be sure open always wins?

Does closing the door have to come at the cost of a technically clean
solution? Doing validation in the kernel to enforce an ideological
position would severely degrade mlx5, and would probably never really
be robust.

Jason