|
|
Log in / Subscribe / Register

watch_mount(), watch_sb(), and fsinfo() (again)

watch_mount(), watch_sb(), and fsinfo() (again)

Posted Feb 28, 2020 14:43 UTC (Fri) by dhowells (guest, #55933)
In reply to: watch_mount(), watch_sb(), and fsinfo() (again) by maxfragg
Parent article: watch_mount(), watch_sb(), and fsinfo() (again)

I'm trying to make a generic notification system, with such properties as:
- messages can be longer than 8 bytes (say up to 128 bytes);
- message queueing requires no on-the-spot allocation and can be done from softirq/irq context or inside spinlocks;
- messages can come from a variety of sources (e.g. mount(2), add_key(2), keyctl(2), sb errors, usb notifications, ...);
- messages from different sources can be in the same queue;
- messages may need copying into multiple queues;
- filters can be easily employed;
- message loss reporting.

As has been mentioned, there are existing solutions:
- Netlink:
- would make the core VFS dependent on the networking code.
- would require GFP_ATOMIC message allocation at the point of generation (at least sometimes).
- doesn't seem to make it easy to do message loss reporting.
- epoll is for dealing with file descriptors - but we're not dealing with fd events.
- Not all sources I need notifications for can be addressed with fanotify.
- eventfd() has 8-byte messages.

Pipes have disadvantages too: no message loss reporting (I'm having to add it); pipe ring buffer metadata elements generally larger than common messages (might be able to optimise in future to store small data in the ring). Note that I didn't want to use pipes either: I was originally using a mappable chardev ring buffer but Linus said I had to use pipes instead.


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds