Thread (14 messages) 14 messages, 8 authors, 2022-03-01

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

From: Luis Chamberlain <mcgrof@kernel.org>
Date: 2022-02-28 22:13:56
Also in: linux-fsdevel

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