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
