[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220521124559.69414fec@hermes.local>
Date: Sat, 21 May 2022 12:45:59 -0700
From: Stephen Hemminger <stephen@...workplumber.org>
To: Kent Overstreet <kent.overstreet@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
netdev@...r.kernel.org, mcgrof@...nel.org, tytso@....edu
Subject: Re: RFC: Ioctl v2
On Sat, 21 May 2022 12:45:46 -0400
Kent Overstreet <kent.overstreet@...il.com> 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.
Netlink was built for networking operations, you want to set something like a route with a large
number of varying parameters in one transaction. And you don't want to have to invent
a new system call every time a new option is added.
Also, you want to monitor changes and see these events for a userspace control
application such as a routing daemon.
Powered by blists - more mailing lists