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 12:45:46 -0400
From:   Kent Overstreet <kent.overstreet@gmail.com>
To:     Andrew Lunn <andrew@lunn.ch>
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: <20220521164546.h7huckdwvguvmmyy@moria.home.lan>
References: <20220520161652.rmhqlvwvfrvskg4w@moria.home.lan>
 <Yof6hsC1hLiYITdh@lunn.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Yof6hsC1hLiYITdh@lunn.ch>
Precedence: bulk

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?

From what I've seen all we really want is driver private syscalls, and the
things about ioctls that suck are where it's _not_ like syscalls. Let's just
make it work more like normal function calls.