3 ms·

I'm not sure what use case you're thinking of here. All requirements that you list are bread and butter for filesystem-based operations. - which user/privilege

by tremon 3y ago

I'm not sure what use case you're thinking of here. All requirements that you list are bread and butter for filesystem-based operations. - which user/privilege level is the caller running as? the kernel already knows this. Which file-based operation doesn't know the privilege level of the caller? - highly and quickly reactive (or what we used to call "event driven") inotify/fsnotify? - impose authentication and access controls built-in to the filesystem, or use SO_PEERCRED on sockets? - and there's no pre-defined schema What do you mean with "schema" here? Are you saying that /proc and /sys have no pre-defined schema? AFAIK, the only thing that files cannot do by default is data broadcast: if you have multiple readers on a file or socket, only one of them will receive the data written. For that, you would need to keep track of the number of readers and give each (passive) listener its own connection.

freedomben 3y ago
> What do you mean with "schema" here? Are you saying that /proc and /sys have no pre-defined schema? If all you're doing is reading/writing kernel stuff, then those will be sufficient. But if you're building a user-space service or daemon that will read/write to/from other user-space processes, then /proc and /sys don't help. If you want to use files you will have to agree and standardize on a format. For example, use YAML? ok, but which properties are mandatory, which are optional? What will their hierarchy look like? Even what is (are) the file name(s)? How do you handle adding/removing properties, maintaining backward compatibilty? > inotify/fsnotify? You can get a lot done with inotify and fsnotify, but there's a lot of overhead involved too. It is also somewhat fragile, some might say "hacky". It's certainly not something I would want to build on top of for a production important service. If you want a reliable Pub-Sub, (so for example, your new application1 wants to subscribe to a number of different types of events/notifications about network changes from Network Manager) you have to hope that NetworkManager is writing that to files, find out which files it is, register a watch on them, read them when they change, parse the data (and have to agree on a data format or "schema" with NetworkManager), and do your thing. Now want to send something back to Network Manager based on what you read? Gotta write to a file, and hope that NetworkManager is already coded to watch that file with inotify/fsnotify, and already agrees with the data format (or "schema"). When you control both sides it's not hard, but when both sides are completely independent with their own goals/priorities and preferences, it can get hairy. These are largely problems that go away with something like D-Bus.

by tremon 3y ago

freedomben 3y ago

> What do you mean with "schema" here? Are you saying that /proc and /sys have no pre-defined schema? If all you're doing is reading/writing kernel stuff, then those will be sufficient. But if you're building a user-space service or daemon that will read/write to/from other user-space processes, then /proc and /sys don't help. If you want to use files you will have to agree and standardize on a format. For example, use YAML? ok, but which properties are mandatory, which are optional? What will their hierarchy look like? Even what is (are) the file name(s)? How do you handle adding/removing properties, maintaining backward compatibilty? > inotify/fsnotify? You can get a lot done with inotify and fsnotify, but there's a lot of overhead involved too. It is also somewhat fragile, some might say "hacky". It's certainly not something I would want to build on top of for a production important service. If you want a reliable Pub-Sub, (so for example, your new application1 wants to subscribe to a number of different types of events/notifications about network changes from Network Manager) you have to hope that NetworkManager is writing that to files, find out which files it is, register a watch on them, read them when they change, parse the data (and have to agree on a data format or "schema" with NetworkManager), and do your thing. Now want to send something back to Network Manager based on what you read? Gotta write to a file, and hope that NetworkManager is already coded to watch that file with inotify/fsnotify, and already agrees with the data format (or "schema"). When you control both sides it's not hard, but when both sides are completely independent with their own goals/priorities and preferences, it can get hairy. These are largely problems that go away with something like D-Bus.