Re: RFC: Ioctl v2
From: Andrew Lunn <andrew@lunn.ch>
Date: 2022-05-21 18:56:18
Also in:
linux-block, linux-fsdevel, lkml
On Sat, May 21, 2022 at 12:45:46PM -0400, Kent Overstreet wrote:
On Fri, May 20, 2022 at 10:31:02PM +0200, Andrew Lunn wrote:quoted
quoted
I want to circulate this and get some comments and feedback, and if no one raises any serious objections - I'd love to get collaborators to work on this with me. Flame away!Hi Kent I doubt you will get much interest from netdev. netdev already considers ioctl as legacy, and mostly uses netlink and a message passing structure, which is easy to extend in a backwards compatible manor.The more I look at netlink the more I wonder what on earth it's targeted at or was trying to solve. It must exist for a reason, but I've written a few ioctls myself and I can't fathom a situation where I'd actually want any of the stuff netlink provides. Why bother with getting a special socket type? Why asynchronous messages with all the marshalling/unmarshalling that entails?
Hi Kent It has its uses, but my main point was, it is unlikely netdev will buy into anything else.
quoted
From what I've seen all we really want is driver private syscalls
netdev is actually very opposed to private syscalls. Given the chance,
each driver will define its own vendor specific APIs, there will be
zero interoperability, you need vendor tools, the documentation will
be missing etc. So netdev tries very hard to have well defined APIs
which are vendor neutral to cover anything a driver, or the network
stack, wants to do.
Andrew