Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Sat, 21 May 2022 20:55:49 +0200
From:   Andrew Lunn <andrew@lunn.ch>
To:     Kent Overstreet <kent.overstreet@gmail.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-block@vger.kernel.org, netdev@vger.kernel.org,
        mcgrof@kernel.org, tytso@mit.edu
Subject: Re: RFC: Ioctl v2
Message-ID: <Yok1tZdl/xmEiQGZ@lunn.ch>
References: <20220520161652.rmhqlvwvfrvskg4w@moria.home.lan>
 <Yof6hsC1hLiYITdh@lunn.ch>
 <20220521164546.h7huckdwvguvmmyy@moria.home.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220521164546.h7huckdwvguvmmyy@moria.home.lan>
Precedence: bulk

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:
> > > 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.

> >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