Hi Jude, On 12/06/2014 03:36 AM, Jude Nelson wrote:
I'm convinced that per-service filesystems encourage modularity better than dbus to the point that I've gone ahead and created a library, called fskit , that makes it easy to embed them into services.
As I mentioned in my other message, this looks like what Plan 9 is doing. I think this is a natural solution to the problem, and history bears that out. Unlike FUSE, fskit
handles all the bookkeeping required to maintain a POSIX-y directory hierarchy, and lets the service programmer define WSGI-style routes to handle I/O operations over sets of paths (a multi-threaded RAM filesystem can be had in about 200 lines of C). It's almost ready for a stable release--it's only missing symlink and hard-link support at this point--but I've already used it to create a special RAM filesystem, called runfs , that automatically removes files once the process that created them dies (i.e. no more stale PID files). I use it every day to avoid polluting my /tmp with files generated (but not cleaned up) by software I work on at $DAYJOB.
How does this compare to tmpfs?
Before I dive off the deep end into doing something big like re-implementing udev, I'm looking for a sanity check. Is what I'm trying to do a desirable, or even a sensible, approach towards encouraging a more modular debian? To be clear, it's not that I dislike dbus; it's that the lack of generic interfaces between dbus components makes it difficult for me to avoid tightly coupling multiple dbus services together. I think this can be avoided if services stuck to generic conventions for interacting with the rest of the system (such as the POSIX filesystem API), since then existing tools would not need to be designed around the services' otherwise-arbitrary methods and their arbitrary side-effects. I think making it easy for services to expose functionality through the filesystem is a big step in this direction.
As I mentioned, this appears to be what Plan 9 is doing with the "everything is a file" paradigm. It looks very much like a step in the right direction, but I am just learning (just in the last few weeks).
Any thoughts or feedback welcome :)
IPC touching everything in the system (and kernel through kdbus, eventually) means this is a big reorganization of userspace, maybe on
the order of what systemd is trying to do. It probably puts you in head-to-head competition with systemd. I think everyone is coming to grips with the scale of the problem, but you seem ahead of the game in terms of a possible solution.
Regards, Jude  http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt  https://github.com/jcnelson/fskit  https://github.com/jcnelson/runfs On Thu, Dec 4, 2014 at 5:36 PM, Martinx - ジェームズ <thiagocmartinsc@xxxxxxxxx> wrote:On 4 December 2014 at 14:03, David L. Craig <dlc.usa@xxxxxxxxx> wrote: > Can we agree dbus is to be avoided? I'm using Linux since 1996 (Debian since Potato), never used dbus (on servers) in my entire life. I see no reason to start using now. Cheers!