Thread (11 messages) 11 messages, 6 authors, 2022-06-09

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help