Re: [PATCH 2/8] fwctl: Basic ioctl dispatch for the character device

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Jun 05, 2024 at 05:42:51PM +0200, Przemek Kitszel wrote:
> On 6/3/24 17:53, Jason Gunthorpe wrote:
> > Each file descriptor gets a chunk of per-FD driver specific context that
> > allows the driver to attach a device specific struct to. The core code
> > takes care of the memory lifetime for this structure.
> > 
> > The ioctl dispatch and design is based on what was built for iommufd. The
> > ioctls have a struct which has a combined in/out behavior with a typical
> > 'zero pad' scheme for future extension and backwards compatibility.
> 
> I would go one step further and introduce a new syscall, that would
> smooth out typical problems of ioctl, and base it on some TLV scheme
> (similar to netlink, in some kind a way smaller brother of protobuf).
> Perhaps with the name more broad than fw-knob-tuning.

We did a TLV scheme like netlink for RDMA. It is very complex and
frankly I think it is overkill for what this wants to do. It suited
RDMA because the system call interface is so vast there.

If the kernel had a general TLV path as an alternative to ioctl it
could be very interesting. I thought about generalizing the RDMA stuff
once, and even gave a small talk at LPC on some of the ideas, but
didn't have the bravery or justification to actually try to do it.

> Then I would go two steps back and a driver layer to interpert those
> syscalls to have at least some sort of openness.

I don't envision having thick drivers marshaling and unmarshaling FW
messages to obfuscate the data flow. The purpose here is what it says
on the label, to be a thin and simple path to sends native commands
with a security apparatus.

Jason