3 ms·
Except Linux hasn't really done this for a while. Most things in Linux are managed via some type of message parsing these days anyway - i.e. you don't configure
by XorNot 2y ago
Except Linux hasn't really done this for a while. Most things in Linux are managed via some type of message parsing these days anyway - i.e. you don't configure devices - really - by /dev/ entries, instead you use the /dev/ entry as the target for an ioctl call which basically does whatever it wants. It's not really file-like at all.
Then there's network which is configured usefully by netlink, which is another message passing protocol.
It doesn't seem like an accident that we keep reinventing socket-based messaging protocols to manage systems, and just "forgetting" to do it the Plan9 way.
- bheadmaster 2y agoFrom client perspective, socket I/O is isomorphic to the file I/O - you get a file descriptor and you read/recv and write/send to it. The only difference is how servers handle it. The ioctl() is different, mostly because it's used to share memory between kernel and userspace, but the same communication pattern could be implemented in file I/O too, probably with performance penalty. Just send the serialized structures, and receive them back. But the goal of DBus was never performance, it was to provide a unified interface to global system services. File I/O here seems like an obvious choice - it's the most fundamental interface that almost every program in the world supports.