You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
68 lines
3.3 KiB
68 lines
3.3 KiB
From af4dc2ff14b020840bf5d4ac3501d639314fb55d Mon Sep 17 00:00:00 2001
|
|
From: illiliti <illiliti@protonmail.com>
|
|
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
|
|
|