From af4dc2ff14b020840bf5d4ac3501d639314fb55d Mon Sep 17 00:00:00 2001 From: illiliti Date: Wed, 8 Sep 2021 21:26:18 +0300 Subject: [PATCH 04/15] readme: rewrite why, add pros/cons --- README.md | 50 +++++++++++++++++++++++++++++++------------------- 1 file changed, 31 insertions(+), 19 deletions(-) --- a/README.md +++ b/README.md @@ -4,25 +4,37 @@ Drop-in replacement for `libudev` intend ## Why? -Because `udev` sucks, it is bloated and overengineered. `udev` is just -like `systemd`, it locks you into using non-portable crap that you can't -avoid because multiple programs depend on it. Look, even FreeBSD was forced -to rewrite[0] this crappy library because `libinput` hard-depends on `udev`. -Without `libinput` you can't use `wayland` and many other cool stuff. - -Michael Forney (author of `cproc`, `samurai`, Oasis Linux, ...) decided to -fork[1] `libinput` and remove the hard dependency on `udev`. However, this -fork has a drawback that requires patching applications to use `libinput_netlink` -instead of the `libinput_udev` API in order to use the automatic detection of -input devices and hotplugging. Static configuration is also required for anything -other than input devices (e.g drm devices). - -Thankfully `udev` has stable API and hopefully no changes will be made to it -the future. On this basis I decided to create this clean-room implementation -of `libudev` which can be used with any or without a device manager. - -[0] https://github.com/FreeBSDDesktop/libudev-devd -[1] https://github.com/oasislinux/libinput +We all know that systemd is very hostile towards portability. Udev inherited +the same problem by exposing a very badly designed library interface. This is +dramatically reduces portability, user choice and basically creates vendor +lock-in because library interface highly tied to udev daemon. + +Another udev problem is non-portable home-grown language called "udev rules". +Udev authors definitely don't know(or care) why it's better to avoid reinventing +the wheel. Strictly speaking, I think they did that on purpose to overcomplicate +udev as much as possible. Why? So that only authors(RedHat/IBM) can rule and dictate +the future of udev. The recent eudev death only proves that it's really hard to +support such unmaintainable mess. + +Udev hwdb is yet another illustration of systemd-like approach. What the hell +"userspace /dev" has to do with parsing hardware database(pci.ids, usb.ids) +and setting/remapping buttons? Udev smells like systemd by trying to implement +all possible functionality in the single daemon/code base. Standalone UNIX-way +programs much better suited for such purposes. + +Keep in mind that libudev-zero isn't ideal. Here is some pros/cons: + +### Pros + +* Very portable. Doesn't depend on GNU features. +* No lock-in. Any device manager can be used, even smdev and CONFIG_UEVENT_HELPER. +* Source code is much cleaner than udev because of less abstractions and clever code. + +### Cons + +* Udev rules must be converted to shell script in order to work with any device manager. +* Udev hwdb interface isn't implemented. pciutils and usbutils will not display any meaningful info. +* Many functions and interfaces still aren't implemented, which may lead to breakage in some programs. ## What doesn't work