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
