[LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Luis Chamberlain]

It would seem we keep tacking on things with ioctls for the block
layer and filesystems. Even for new trendy things like io_uring [0].
For a few years I have found this odd, and have slowly started
asking folks why we don't consider alternatives like a generic
netlink family. I've at least been told that this is desirable
but no one has worked on it. *If* we do want this I think we just
not only need to commit to do this, but also provide a target. LSFMM
seems like a good place to do this.

Possible issues? Kernels without CONFIG_NET. Is that a deal breaker?
We already have a few filesystems with their own generic netlink
families, so not sure if this is a good argument against this.

mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family fs
fs/cifs/netlink.c:      ret = genl_register_family(&cifs_genl_family);
fs/dlm/netlink.c:       return genl_register_family(&family);
fs/ksmbd/transport_ipc.c:       ret = genl_register_family(&ksmbd_genl_family);
fs/quota/netlink.c:     if (genl_register_family(&quota_genl_family) != 0)
mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family drivers/block
drivers/block/nbd.c:    if (genl_register_family(&nbd_genl_family)) {

Are there other reasons to *not* use generic netlink for new features?
For folks with experience using generic netlink on the block layer and
their own fs, any issues or pain points observed so far?

[0] https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=nvme-passthru-wip.2&id=d11e20acbd93fbbcdaf87e73615cdac53b814eca

  Luis

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Matthew Wilcox]

On Mon, Jan 31, 2022 at 05:33:29PM -0800, Luis Chamberlain wrote:
> It would seem we keep tacking on things with ioctls for the block
> layer and filesystems. Even for new trendy things like io_uring [0].

I think the problem is that it's a huge effort to add a new syscall.
You have to get it into each architecture.  Having a single place to
add a new syscall would help reduce the number of places we use
multiplexor syscalls like ioctl().

> For a few years I have found this odd, and have slowly started
> asking folks why we don't consider alternatives like a generic
> netlink family. I've at least been told that this is desirable
> but no one has worked on it.

I don't know that I agree that "generic netlink" is desirable.
I'd like to know more about the pros and cons of this idea.

> Possible issues? Kernels without CONFIG_NET. Is that a deal breaker?
> We already have a few filesystems with their own generic netlink
> families, so not sure if this is a good argument against this.
> 
> mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family fs
> fs/cifs/netlink.c:      ret = genl_register_family(&cifs_genl_family);
> fs/dlm/netlink.c:       return genl_register_family(&family);
> fs/ksmbd/transport_ipc.c:       ret = genl_register_family(&ksmbd_genl_family);
> fs/quota/netlink.c:     if (genl_register_family(&quota_genl_family) != 0)

I'm not sure these are good arguments in favour ... other than quota,
these are all network filesystems, which aren't much use without
CONFIG_NET.

> mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family drivers/block
> drivers/block/nbd.c:    if (genl_register_family(&nbd_genl_family)) {

The, er, _network_ block device, right?

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[James Bottomley]

On Mon, 2022-01-31 at 17:33 -0800, Luis Chamberlain wrote:
> It would seem we keep tacking on things with ioctls for the block
> layer and filesystems. Even for new trendy things like io_uring [0].

And many systems besides ... we're also adding new ioctls for things
like containers.

However, could I just ask why you object to ioctls?  I agree, like any
drug, overuse leads to huge problems.  However, there are medicinal use
cases where they actually save a huge amount of pain.  So I think as
long as we're careful we can still continue using them.

What is the issue?  Just the non-introspectability of the data from the
perspective of tools like seccomp?

> For a few years I have found this odd, and have slowly started
> asking folks why we don't consider alternatives like a generic
> netlink family. I've at least been told that this is desirable
> but no one has worked on it. *If* we do want this I think we just
> not only need to commit to do this, but also provide a target. LSFMM
> seems like a good place to do this.

It's not just netlink.  We have a huge plethora of interfaces claiming
to replace the need for ioctl as a means for exchanging information
between a multiplexor and an in-kernel set of receivers.  The latest
one I noticed would be fsconfig, although that is filesystem specific
(but could be made more generic).  And, of course, configfs was
supposed to be another generic but introspectable configuration
exchange system.  We're quite good at coming up with ioctl replacement,
however when we do they don't seem to be as durable.  I think we should
really examine what we think the problem is in detail before even
starting to propose a solution.

James

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Christian Brauner]

On Mon, Jan 31, 2022 at 05:33:29PM -0800, Luis Chamberlain wrote:
> It would seem we keep tacking on things with ioctls for the block
> layer and filesystems. Even for new trendy things like io_uring [0].
> For a few years I have found this odd, and have slowly started
> asking folks why we don't consider alternatives like a generic
> netlink family. I've at least been told that this is desirable
> but no one has worked on it. *If* we do want this I think we just
> not only need to commit to do this, but also provide a target. LSFMM
> seems like a good place to do this.
> 
> Possible issues? Kernels without CONFIG_NET. Is that a deal breaker?
> We already have a few filesystems with their own generic netlink
> families, so not sure if this is a good argument against this.
> 
> mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family fs
> fs/cifs/netlink.c:      ret = genl_register_family(&cifs_genl_family);
> fs/dlm/netlink.c:       return genl_register_family(&family);
> fs/ksmbd/transport_ipc.c:       ret = genl_register_family(&ksmbd_genl_family);
> fs/quota/netlink.c:     if (genl_register_family(&quota_genl_family) != 0)
> mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family drivers/block
> drivers/block/nbd.c:    if (genl_register_family(&nbd_genl_family)) {
> 
> Are there other reasons to *not* use generic netlink for new features?
> For folks with experience using generic netlink on the block layer and
> their own fs, any issues or pain points observed so far?

Netlink is a giant pain to use for userspace tbh. ioctl()s aren't great
but they are way easier to add and use.

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Steven Whitehouse]

Hi,

On Mon, 2022-01-31 at 17:33 -0800, Luis Chamberlain wrote:
> It would seem we keep tacking on things with ioctls for the block
> layer and filesystems. Even for new trendy things like io_uring [0].
> For a few years I have found this odd, and have slowly started
> asking folks why we don't consider alternatives like a generic
> netlink family. I've at least been told that this is desirable
> but no one has worked on it. *If* we do want this I think we just
> not only need to commit to do this, but also provide a target. LSFMM
> seems like a good place to do this.
> 
> Possible issues? Kernels without CONFIG_NET. Is that a deal breaker?
> We already have a few filesystems with their own generic netlink
> families, so not sure if this is a good argument against this.
> 
> mcgrof@fulton ~/linux-next (git::master)$ git grep
> genl_register_family fs
> fs/cifs/netlink.c:      ret =
> genl_register_family(&cifs_genl_family);
> fs/dlm/netlink.c:       return genl_register_family(&family);
> fs/ksmbd/transport_ipc.c:       ret =
> genl_register_family(&ksmbd_genl_family);
> fs/quota/netlink.c:     if (genl_register_family(&quota_genl_family)
> != 0)
> mcgrof@fulton ~/linux-next (git::master)$ git grep
> genl_register_family drivers/block
> drivers/block/nbd.c:    if (genl_register_family(&nbd_genl_family)) {
> 
> Are there other reasons to *not* use generic netlink for new
> features?
> For folks with experience using generic netlink on the block layer
> and
> their own fs, any issues or pain points observed so far?
> 
> [0] 
> https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git/commit/?h=nvme-passthru-wip.2&id=d11e20acbd93fbbcdaf87e73615cdac53b814eca
> 
>   Luis
> 

I think it depends very much on what the interface is, as to which of
the available APIs (or even creating a new one) is the most appropriate
option.

Netlink was investigated a little while back as a potential interface
for filesystem notifications. The main reason for this is that it
solves one of the main issues there, which is the potentially unbounded
number of notifications that might be issued into a queue of finite
capacity. Netlink was originally designed for network routing messages
which have a similar issue. As such a mechanism was built in to allow
dropping of messages when the queue overflows, but in a way that it is
known that this has happened, so one can then resync from the kernel's
information. For things such as mount notifications, which can be
numerous in various container scenarios, this is an important
requirement.

However, it is also clear that netlink has some disadvantages too. The
first of these is that it is aligned to the network subsystem in terms
of namespaces. Since the kernel has no concept of a container per se,
the fact that netlink is in the network namespace rather than the
filesystem namespace makes using it with filesystems more difficult.
Another issue is that netlink has gained a number of additional
features and layers over the years, leading to some overhead that is
perhaps not needed in applications on the filesystem side.

That is why, having carefully considered the options David Howells
created a new interface for the notifications project. It solves the
problems mentioned above, while still retaining the advantages or being
able to deal with producer/consumer problems.

I'm not sure from the original posting though exactly which interfaces
you had in mind when proposing this topic. Depending on what they are
it is possible that another solution may be more appropriate. I've
included the above mostly as a way to explain what has already been
considered in terms of netlink pros/cons for one particular
application,

Steve.

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Bart Van Assche]

On 1/31/22 17:33, Luis Chamberlain wrote:
> It would seem we keep tacking on things with ioctls for the block
> layer and filesystems. Even for new trendy things like io_uring [0].
> For a few years I have found this odd, and have slowly started
> asking folks why we don't consider alternatives like a generic
> netlink family. I've at least been told that this is desirable
> but no one has worked on it. *If* we do want this I think we just
> not only need to commit to do this, but also provide a target. LSFMM
> seems like a good place to do this.

Do we need a new netlink family for this purpose? The RDMA subsystem 
uses netlink since considerable time for configuration purposes instead 
of ioctls, sysfs or configfs. The user space tool 'rdma' supports that 
interface. That tool is used by e.g. blktests to configure the soft-RoCE 
and soft-iWARP interfaces.

See also rdma(8), available at e.g. 
https://man7.org/linux/man-pages/man8/rdma.8.html.

Bart.

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Jan Kara]

On Tue 01-02-22 02:14:42, Matthew Wilcox wrote:
> On Mon, Jan 31, 2022 at 05:33:29PM -0800, Luis Chamberlain wrote:
> > Possible issues? Kernels without CONFIG_NET. Is that a deal breaker?
> > We already have a few filesystems with their own generic netlink
> > families, so not sure if this is a good argument against this.
> > 
> > mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family fs
> > fs/cifs/netlink.c:      ret = genl_register_family(&cifs_genl_family);
> > fs/dlm/netlink.c:       return genl_register_family(&family);
> > fs/ksmbd/transport_ipc.c:       ret = genl_register_family(&ksmbd_genl_family);
> > fs/quota/netlink.c:     if (genl_register_family(&quota_genl_family) != 0)
> 
> I'm not sure these are good arguments in favour ... other than quota,
> these are all network filesystems, which aren't much use without
> CONFIG_NET.
> 
> > mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family drivers/block
> > drivers/block/nbd.c:    if (genl_register_family(&nbd_genl_family)) {
> 
> The, er, _network_ block device, right?

Yep, and even for the quota what you'll lose with the netlink family are
the fancy out-of-band notifications about users going over their quotas.
Not a big loss. So I don't by this argument.

OTOH these days when even a lightbulb is connected to a network, I don't
personally think CONFIG_NET dependency is a real problem...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Luis Chamberlain]

On Tue, Feb 01, 2022 at 02:14:42AM +0000, Matthew Wilcox wrote:
> On Mon, Jan 31, 2022 at 05:33:29PM -0800, Luis Chamberlain wrote:
> > It would seem we keep tacking on things with ioctls for the block
> > layer and filesystems. Even for new trendy things like io_uring [0].
> 
> I think the problem is that it's a huge effort to add a new syscall.

As we'll all agree it should be.

> You have to get it into each architecture.  Having a single place to
> add a new syscall would help reduce the number of places we use
> multiplexor syscalls like ioctl().

Jeesh, is such a thing really possible? I wonder if Arnd has tried or
what he'd think...

I'm not arguing in favor of this, I am not sure if we want to be
encouraging new syscalls for everything. I'd agree that if its generic
perhaps so, but my own focus on this thread was block / fs.

So my hope with this thread was to encourage discussion for alternatives
to ioctls specifically for the block layer / filesystems.

> > For a few years I have found this odd, and have slowly started
> > asking folks why we don't consider alternatives like a generic
> > netlink family. I've at least been told that this is desirable
> > but no one has worked on it.
> 
> I don't know that I agree that "generic netlink" is desirable.
> I'd like to know more about the pros and cons of this idea.

Yeah it was just an idea example of a framework which does actually
get us closer to some form of real data types for what is being
supported, and which also pushes us to use kdoc.

> > Possible issues? Kernels without CONFIG_NET. Is that a deal breaker?
> > We already have a few filesystems with their own generic netlink
> > families, so not sure if this is a good argument against this.
> > 
> > mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family fs
> > fs/cifs/netlink.c:      ret = genl_register_family(&cifs_genl_family);
> > fs/dlm/netlink.c:       return genl_register_family(&family);
> > fs/ksmbd/transport_ipc.c:       ret = genl_register_family(&ksmbd_genl_family);
> > fs/quota/netlink.c:     if (genl_register_family(&quota_genl_family) != 0)
> 
> I'm not sure these are good arguments in favour ... other than quota,
> these are all network filesystems, which aren't much use without
> CONFIG_NET.

It's a good point.

> > mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family drivers/block
> > drivers/block/nbd.c:    if (genl_register_family(&nbd_genl_family)) {
> 
> The, er, _network_ block device, right?

:) Sure.

  Luis

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Luis Chamberlain]

On Tue, Feb 01, 2022 at 07:56:19AM -0500, James Bottomley wrote:
> On Mon, 2022-01-31 at 17:33 -0800, Luis Chamberlain wrote:
> > It would seem we keep tacking on things with ioctls for the block
> > layer and filesystems. Even for new trendy things like io_uring [0].
> 
> And many systems besides ... we're also adding new ioctls for things
> like containers.
> 
> However, could I just ask why you object to ioctls?  I agree, like any
> drug, overuse leads to huge problems.  However, there are medicinal use
> cases where they actually save a huge amount of pain.  So I think as
> long as we're careful we can still continue using them.

Getting to the point we are comparing use of ioctls with drugs is a good
indication we probably haven't given much thought to our sloppy dependency on
them.

> What is the issue?  Just the non-introspectability of the data from the
> perspective of tools like seccomp?

That's one. The opaque nature is silly. I can run blktrace on tons of
my /dev/ files and do *interesting* stupid things. This just seems
plain wrong...

> > For a few years I have found this odd, and have slowly started
> > asking folks why we don't consider alternatives like a generic
> > netlink family. I've at least been told that this is desirable
> > but no one has worked on it. *If* we do want this I think we just
> > not only need to commit to do this, but also provide a target. LSFMM
> > seems like a good place to do this.
> 
> It's not just netlink.  We have a huge plethora of interfaces claiming
> to replace the need for ioctl as a means for exchanging information
> between a multiplexor and an in-kernel set of receivers.

Yes and with io-uring cmd coming into my radar, and folks wanting to
do things like io-uring for ioctls get's me thinking this is just
going to get sloppier. I admit I like the idea of io-uring cmd for
ioctls but I would have to think that's our future.

> The latest
> one I noticed would be fsconfig, although that is filesystem specific
> (but could be made more generic).

Thanks I'll check that out.

> And, of course, configfs was
> supposed to be another generic but introspectable configuration
> exchange system.  We're quite good at coming up with ioctl replacement,
> however when we do they don't seem to be as durable.  I think we should
> really examine what we think the problem is in detail before even
> starting to propose a solution.

Sure, and evaluate what solutions already exist.

Alrighty, so as an example... I recall when we were working on trying to
avoid doing the stupid ioctl mess with wireless. Yes it made sense to
use generic netlink, but the results are quite impressive if you ask me
in terms of clarify and documentation:

include/uapi/linux/nl80211.h

So I can't be doing stupid things like sending a NL80211_CMD_GET_BEACON
command to an ethernet device, for instance. But that's not just it. The
clear specification of data types is great.

ioctls for new features for fileystems / the block layer just makes
them seem almost cavemen like. And that we don't stop and seem to have
a clear north star for an alternative does get me to ask do we really
want an alternative and if so so well let's get to it.

  Luis

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Luis Chamberlain]

On Tue, Feb 01, 2022 at 02:20:48PM +0100, Christian Brauner wrote:
> On Mon, Jan 31, 2022 at 05:33:29PM -0800, Luis Chamberlain wrote:
> > It would seem we keep tacking on things with ioctls for the block
> > layer and filesystems. Even for new trendy things like io_uring [0].
> > For a few years I have found this odd, and have slowly started
> > asking folks why we don't consider alternatives like a generic
> > netlink family. I've at least been told that this is desirable
> > but no one has worked on it. *If* we do want this I think we just
> > not only need to commit to do this, but also provide a target. LSFMM
> > seems like a good place to do this.
> > 
> > Possible issues? Kernels without CONFIG_NET. Is that a deal breaker?
> > We already have a few filesystems with their own generic netlink
> > families, so not sure if this is a good argument against this.
> > 
> > mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family fs
> > fs/cifs/netlink.c:      ret = genl_register_family(&cifs_genl_family);
> > fs/dlm/netlink.c:       return genl_register_family(&family);
> > fs/ksmbd/transport_ipc.c:       ret = genl_register_family(&ksmbd_genl_family);
> > fs/quota/netlink.c:     if (genl_register_family(&quota_genl_family) != 0)
> > mcgrof@fulton ~/linux-next (git::master)$ git grep genl_register_family drivers/block
> > drivers/block/nbd.c:    if (genl_register_family(&nbd_genl_family)) {
> > 
> > Are there other reasons to *not* use generic netlink for new features?
> > For folks with experience using generic netlink on the block layer and
> > their own fs, any issues or pain points observed so far?
> 
> Netlink is a giant pain to use for userspace tbh. ioctl()s aren't great
> but they are way easier to add and use.

We trade ease-of use for sloppiness. We must accept that at least.

  Luis

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Luis Chamberlain]

On Wed, Feb 02, 2022 at 12:36:12PM -0800, Bart Van Assche wrote:
> On 1/31/22 17:33, Luis Chamberlain wrote:
> > It would seem we keep tacking on things with ioctls for the block
> > layer and filesystems. Even for new trendy things like io_uring [0].
> > For a few years I have found this odd, and have slowly started
> > asking folks why we don't consider alternatives like a generic
> > netlink family. I've at least been told that this is desirable
> > but no one has worked on it. *If* we do want this I think we just
> > not only need to commit to do this, but also provide a target. LSFMM
> > seems like a good place to do this.
> 
> Do we need a new netlink family for this purpose? The RDMA subsystem uses
> netlink since considerable time for configuration purposes instead of
> ioctls, sysfs or configfs. The user space tool 'rdma' supports that
> interface. That tool is used by e.g. blktests to configure the soft-RoCE and
> soft-iWARP interfaces.
> 
> See also rdma(8), available at e.g.
> https://man7.org/linux/man-pages/man8/rdma.8.html.

RDMA is netork'ish though.

But my point is not just to consider generic netlink, it's just an
example. I'm just flabbergasted we're still adding ioctls for new
random filesystem or block features.

  Luis

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Luis Chamberlain]

On Wed, Feb 02, 2022 at 10:39:46AM +0000, Steven Whitehouse wrote:
> I think it depends very much on what the interface is, as to which of
> the available APIs (or even creating a new one) is the most appropriate
> option.
> 
> Netlink was investigated a little while back as a potential interface
> for filesystem notifications. The main reason for this is that it
> solves one of the main issues there, which is the potentially unbounded
> number of notifications that might be issued into a queue of finite
> capacity. Netlink was originally designed for network routing messages
> which have a similar issue. As such a mechanism was built in to allow
> dropping of messages when the queue overflows, but in a way that it is
> known that this has happened, so one can then resync from the kernel's
> information. For things such as mount notifications, which can be
> numerous in various container scenarios, this is an important
> requirement.

Got it, this helps thanks. Curious if it was looked into if there
could be an option where the drops *cannot* happen. Just curious.

> However, it is also clear that netlink has some disadvantages too. The
> first of these is that it is aligned to the network subsystem in terms
> of namespaces. Since the kernel has no concept of a container per se,
> the fact that netlink is in the network namespace rather than the
> filesystem namespace makes using it with filesystems more difficult.

OK thanks for sharing this, so what makes it difficult exactly?
What was not possible, other than this indeed beign really odd?

> Another issue is that netlink has gained a number of additional
> features and layers over the years, leading to some overhead that is
> perhaps not needed in applications on the filesystem side.

Curious if not netlink but generic netlink was evaluated?

> That is why, having carefully considered the options David Howells
> created a new interface for the notifications project. It solves the
> problems mentioned above, while still retaining the advantages or being
> able to deal with producer/consumer problems.

I see.

> I'm not sure from the original posting though exactly which interfaces
> you had in mind when proposing this topic. Depending on what they are
> it is possible that another solution may be more appropriate. I've
> included the above mostly as a way to explain what has already been
> considered in terms of netlink pros/cons for one particular
> application,

Yes thanks this helps a lot! I knew we had beers over this years ago,
and I think we both seemed stunned no alternatives were in sight then.

  Luis

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Arnd Bergmann]

On Mon, Feb 28, 2022 at 10:46 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> On Tue, Feb 01, 2022 at 02:14:42AM +0000, Matthew Wilcox wrote:
> > On Mon, Jan 31, 2022 at 05:33:29PM -0800, Luis Chamberlain wrote:
> > You have to get it into each architecture.  Having a single place to
> > add a new syscall would help reduce the number of places we use
> > multiplexor syscalls like ioctl().
>
> Jeesh, is such a thing really possible? I wonder if Arnd has tried or
> what he'd think...

Definitely possible, Firoz Khan was working on this at Linaro, but he
never finished it before he left. I still have his patches if anyone wants
to pick it up, though it might be easier to start over at this point.

The main work that is required here is to convert
include/uapi/asm-generic/unistd.h into the syscall.tbl format,
with a number of architecture specific conditionals to deal with all
the combinations of syscalls that may or may not be used on a given
target.

After that, I would modify the scripts/syscall*.sh scripts to allow
multiple input files, splitting the architecture specific numbers
(under 400) from the newer numbers (over 400) that can be
shared between all architectures in a single location.

        Arnd

Re: [LSF/MM/BPF TOPIC] are we going to use ioctls forever?

[Luis Chamberlain]

On Tue, Mar 01, 2022 at 08:47:47AM +0100, Arnd Bergmann wrote:
> On Mon, Feb 28, 2022 at 10:46 PM Luis Chamberlain <mcgrof@kernel.org> wrote:
> > On Tue, Feb 01, 2022 at 02:14:42AM +0000, Matthew Wilcox wrote:
> > > On Mon, Jan 31, 2022 at 05:33:29PM -0800, Luis Chamberlain wrote:
> > > You have to get it into each architecture.  Having a single place to
> > > add a new syscall would help reduce the number of places we use
> > > multiplexor syscalls like ioctl().
> >
> > Jeesh, is such a thing really possible? I wonder if Arnd has tried or
> > what he'd think...
> 
> Definitely possible, Firoz Khan was working on this at Linaro, but he
> never finished it before he left. I still have his patches if anyone wants
> to pick it up, though it might be easier to start over at this point.
> 
> The main work that is required here is to convert
> include/uapi/asm-generic/unistd.h into the syscall.tbl format,
> with a number of architecture specific conditionals to deal with all
> the combinations of syscalls that may or may not be used on a given
> target.
> 
> After that, I would modify the scripts/syscall*.sh scripts to allow
> multiple input files, splitting the architecture specific numbers
> (under 400) from the newer numbers (over 400) that can be
> shared between all architectures in a single location.

It is not a requirement for us, but this is good to know. Thanks!

  Luis