Mastodawn

Laurent Bercot

@rose real question, what was wrong with mdevd + libudev-zero that you needed to reimplement the full mechanism? Are there hooks I could add to mdevd that would make it usable as a device manager (without the libudev layer, of course) in more cases than it currently is?

Apart from support for systemd-udevs rule files, systemd-udev maintains a database of a bunch of device data in /run/udev, the main thing that gardendev does is process udev rules and populate the database

The one thing that I think would make mdevd more suited for desktop use is more advanced options in configs, but I'm not sure if things like uaccess are something you want to add, they're kinda messy designs

Laurent Bercot Apr 5

@rose not sure what uaccess is, but it seems to me that anything you'd need to add could be achieved via program execution lines in mdev.conf. That's what mdev-like-a-boss does.

Every systemd-udev rule bulitin would have to be implemented as its own executable, which is definetly possible, but with having to populate a database either way I felt like having it all in one daemon would be (for now) a better solution

@rose @ska

this feels oddly familiar to mdev vs mdevd =w=

what do you mean?

CC: @[email protected]

@rose @ska

as far as i know, mdev from busybox would register itself to handle events, and get spawned by the kernel on every event, then have to load it's config file and handle the event, every time

while mdevd uses the same config, but is a daemon and avoids a pretty massive overhead

or so i have been told

@rose @ska

it would probably matter way less to a "stateless" gardendev that is just executables, since if we can port all .rules to be mdev executions, then we don't have to load configs every time, though

oh, yes, if it'd be executables they definetly would have to be stateless, loading configs for every call would be annoying

CC: @[email protected] @[email protected]

Laurent Bercot Apr 5

@rose @navi yes, the problem with mdev hotplug invocations was

no synchronization mechanism, so no guaranteed ordering unless you manually used the sequencing feature for that, which had its own issue (I don't remember but I think it was busylooping or something)
parsing the config file for every event

mdevd solves these aspects, and spawning an additional helper for every (or most) uevent isn't prohibitively expensive thanks to posix_spawn()

@ska @rose doesn't help that libudev-zero was also full of stubs

that one can't really implement without the whole database and tag tracking of udev (and now of gardendev too)

yeah, in the long run I'd like to have gardendev only populate a database for libudev-zero, while mdevd is what handles the configs
I have a udev to mdev config translator tool as part of gardendev, but havent had the chance to test it yet

CC: @[email protected]