lvm2 does not build with the following errors.

/usr/bin/ld: ../../libdm/libdevmapper.so: undefined reference to `udev_queue_get_udev_is_active'
/usr/bin/ld: ../../libdm/libdevmapper.so: undefined reference to `udev_queue_unref'
/usr/bin/ld: ../../libdm/libdevmapper.so: undefined reference to `udev_queue_new'

It may be user error any help would be appreciated.

over at alpine linux, we recently had some issues relating to improperly mixing libraries linked against libudev-zero static library with eudev dynamic library. this caused us quite a bit of grief, because in certain circumstances this issue is not diagnosed by static or dynamic linker, and explodes very confusingly at runtime due to totally incompatible data structures.

therefore, I would like to suggest removing the static library or at least not installing it by default. I think it is a major footgun for users, and the overhead of loading and calling a separate dynamic library is negligible, especially compared to actually probing and interacting with devices.

thanks!

Hi illiliti.

I think libudev-zero is good solution for linux container guest. I respect to your work.
Current libudev-zero build by standalone Makefile, it's not support build time configuration change such as enabling helper, install mdev support and etc...
I propose to migrate automake/autoconf from standalone Makefile. If it fine, I will contribute.

So, everything that uses wayland works perfectly fine.
As soon as I open any app using x11 (xwayland) - sway crashes.

Here is sway -V -d output.
https://pastebin.com/g2bmmQmc
I launch alacritty and then mpv --gpu-context=x11egl afile.mkv

The issue is not present if I switch to eudev.
Setup - Alpine on laptop with integrated and dedicated AMD graphics.
I was unable to detect anything unusual while using gdb with sway, but I'm willing to use gdb again if you tell me how and what should I use it with.

intel_gpu_top suffers a segmentation upon starting up if using libudev-zero (stock libudev, even without udevd running, works).

Backtrace:

#0  0x00007ffff7cca91e in ?? () from /lib64/libc.so.6
No symbol table info available.
#1  0x0000555555561ab1 in igt_device_find (subsystem=0x0, syspath=0x555555574f20 "/sys/devices/pci0000:00") at ../lib/igt_device_scan.c:500
        dev = 0x555555574470
#2  0x0000555555562062 in update_or_add_parent (dev=0x555555574c70, idev=0x55555557a7d0) at ../lib/igt_device_scan.c:642
        parent_dev = 0x555555574e90
        parent_idev = 0x555555561a73 <igt_device_new_from_udev+335>
        subsystem = 0x0
        syspath = 0x555555574f20 "/sys/devices/pci0000:00"
        devname = 0x55555557a7d0 ""
        __func__ = "update_or_add_parent"
#3  0x00005555555626b3 in scan_drm_devices () at ../lib/igt_device_scan.c:778
        path = 0x7fffe0000e10 "/sys/devices/pci0000:00/0000:00:02.0"
        udev_dev = 0x555555574c70
        idev = 0x55555557a7d0
        udev = 0x555555573ca0
        enumerate = 0x555555573cc0
        devices = 0x7fffe0000e40
        dev_list_entry = 0x7fffe0000df0
        dev = 0x52
        ret = 0
        __func__ = "scan_drm_devices"
#4  0x00005555555629ba in igt_devices_scan (force=false) at ../lib/igt_device_scan.c:851
No locals.
#5  0x00005555555601cb in main (argc=1, argv=0x7fffffffe4d8) at ../tools/intel_gpu_top.c:2479
        period_us = 1000000
        clients = 0x0
        con_w = -1
        con_h = -1
        output_path = 0x0
        engines = 0xff000000
        ret = 0
        ch = -1
        list_device = false
        pmu_device = 0x0
        opt_device = 0x0
        card = {
[...]

I had the fortunate experience of having my keyboard report keys greater than X can handle. Of course this wasn't a problem with Arch/udev because it was handled by the hwdb

In my case a file like this in etc/udev/hwdb.d/90-thinkpad-keyboard.hwdb was all that was needed:

evdev:name:ThinkPad Extra Buttons:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*
 KEYBOARD_KEY_49=playpause

To me the ideal is to be able to reuse the files so we don't have to re-setup every device.

Attempt 1

And I noticed form udevadm info that KEYBOARD_KEY_49 property appeared along with the ID_INPUT_KEYBOARD which udev-zero sets. So I was thinking we could just parse these database files and set the properties ourselves for the matching devices. For each device, we'd just have to compare the regex in the database file to one of the 3 patterns defined here. Seems straightforward enough and have a draft ready... However when I tried to manually set the KEYBOARD_KEY_49 property in udev_device.c, I didn't see an effect. Open to suggestions.

Attempt 2

The arch wiki details on how to manually remap keycodes via setkeycodes. It is easy enough to find all hwdb files, parse then and manually set the keycodes. The script could be run standalone as setkeycodes affects global mapping and isn't per device.

And while I was working on this, I started wondering if anyone really cared. I think being able to change mappings per device is cool in theory, but don't have any hardware where a global change wouldn't suffice. Also, although the udev database allows some extra keys to be recognized, they still report the wrong keysym by default. And if you want to modify the keyboard layout to have the correct keysyms, having a startup file to explicitly remap the keycodes seems pretty reasonable.

Udev hwdb interface isn't implemented. pciutils and usbutils will not display any meaningful info.

So is lack of hwdb really a con? lspci from pciutils displays meaningfull info for me. I could see a benefit if one wanted to set some static configuration for a device at the libinput layer.

Anyways was curious if anyone else put thought into this and/or knew what I was doing wrong in my first attempt

Yambar's battery module uses udev_monitor functions to query for battery state. It seems to work fine on startup, but as soon as the state changes (e. g. plug and unplug) it suffers a segmentation fault.

A stock libudev.so.1 doesn't trigger the issue, and state changes are monitored appropriately even when udevd is not running.

Backtrace (built from git master 76225a8366fa15b2fd45611a0e0961e72c7e7120):

#0  0x00007ffff7b5391a in ?? () from /lib64/libc.so.6
#1  0x000055555557b9b8 in run (mod=0x5555557f2770) at ../modules/backlight.c:194
#2  0x00007ffff7bc6e4a in start_thread () from /lib64/libpthread.so.0
#3  0x00007ffff7afb47f in clone () from /lib64/libc.so.6
(gdb) bt full
#0  0x00007ffff7b5391a in ?? () from /lib64/libc.so.6
No symbol table info available.
#1  0x000055555557b9b8 in run (mod=0x5555557f2770) at ../modules/backlight.c:194
        fds = {{fd = 3, events = 1, revents = 0}, {fd = 10, events = 1, revents = 1}}
        dev = 0x0
        sysname = 0x0
        is_us = false
        bar = 0x5555557f35a0
        m = 0x5555557d5800
        current_fd = 9
        udev = 0x7fffec000dd0
        mon = 0x7fffec000df0
#2  0x00007ffff7bc6e4a in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3  0x00007ffff7afb47f in clone () from /lib64/libc.so.6
No symbol table info available.

Relevant function:

static int
run(struct module *mod)
{
    const struct bar *bar = mod->bar;
    struct private *m = mod->private;

    int current_fd = initialize(m);
    if (current_fd == -1)
        return 1;

    struct udev *udev = udev_new();
    struct udev_monitor *mon = udev_monitor_new_from_netlink(udev, "udev");

    if (udev == NULL || mon == NULL) {
        LOG_ERR("failed to initialize udev monitor");

        if (udev == NULL)
            udev_unref(udev);

        close(current_fd);
        return 1;
    }

    udev_monitor_filter_add_match_subsystem_devtype(mon, "backlight", NULL);
    udev_monitor_enable_receiving(mon);

    bar->refresh(bar);

    while (true) {
        struct pollfd fds[] = {
            {.fd = mod->abort_fd, .events = POLLIN},
            {.fd = udev_monitor_get_fd(mon), .events = POLLIN},
        };
        poll(fds, 2, -1);

        if (fds[0].revents & POLLIN)
            break;

        struct udev_device *dev = udev_monitor_receive_device(mon);
        const char *sysname = udev_device_get_sysname(dev);

        bool is_us = strcmp(sysname, m->device) == 0; // causes the segmentation fault
        udev_device_unref(dev);

        if (!is_us)
            continue;

        mtx_lock(&mod->lock);
        m->current_brightness = readint_from_fd(current_fd);
        mtx_unlock(&mod->lock);
        bar->refresh(bar);
    }

    udev_monitor_unref(mon);
    udev_unref(udev);

    close(current_fd);
    return 0;
}

Possible to work on any MacOS?

Depends on:
linux/input.h
sys/sysmacros.h

The sysmacros.h is no problem, but the input.h
Any idea, what to do, to bring this to a Mac?

Thank's anyway...

meson.build:48:14: ERROR: Dependency lookup for libudev with method 'pkgconfig' failed: Invalid version, need 'libudev' ['>= 251'] found '243'.

or, if manually patch libgudev's meson.build:

[2/7] Compiling C object gudev/libgudev-1.0.a.p/gudevdevice.c.o
FAILED: gudev/libgudev-1.0.a.p/gudevdevice.c.o 
clang -Igudev/libgudev-1.0.a.p -Igudev -I../src/gudev -I. -I../src -I/ix/store/uLZwZLFmS7MUKLco-lib-glib-ix/include/glib-2.0 -I/ix/store/uLZwZLFmS7MUKLco-lib-glib-ix/lib/glib-2.0/include -I/ix/store/GPIWf4WiE7ZIx2wg-lib-pcre-2/include -I/ix/store/uLZwZLFmS7MUKLco-lib-glib-ix/include -I/ix/store/ZufDx1e6EVfFCuNi-lib-ffi/include -I/ix/store/IZd80D0arFljmJVh-lib-udev-zero/include -fcolor-diagnostics -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O2 -g -Wno-unknown-warning-option -fPIC -pthread -DHAVE_CONFIG_H -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_GUDEV_COMPILATION -D_GUDEV_WORK_AROUND_DEV_T_BUG '-DG_LOG_DOMAIN="GUdev"' -MD -MQ gudev/libgudev-1.0.a.p/gudevdevice.c.o -MF gudev/libgudev-1.0.a.p/gudevdevice.c.o.d -o gudev/libgudev-1.0.a.p/gudevdevice.c.o -c ../src/gudev/gudevdevice.c
../src/gudev/gudevdevice.c:146:12: error: call to undeclared function 'udev_device_get_current_tags_list_entry'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  for (l = udev_device_get_current_tags_list_entry (device->priv->udevice); l != NULL; l = udev_list_entry_get_next (l))
           ^
../src/gudev/gudevdevice.c:146:12: note: did you mean 'udev_device_get_tags_list_entry'?
/ix/store/IZd80D0arFljmJVh-lib-udev-zero/include/libudev.h:72:25: note: 'udev_device_get_tags_list_entry' declared here
struct udev_list_entry *udev_device_get_tags_list_entry(struct udev_device *udev_device);
                        ^
1 error generated.

Hello

I'm trying to compile hid2hci.c ( https://git.osdn.net/view?p=android-x86/external-bluetooth-bluez.git;a=blob;f=tools/hid2hci.c;h=8f060f2580c863f57ca5d474d6aa89b399208c07;hb=refs/heads/r-x86 ) using clang C compiler on Termux. Is it possible to install libdev-zero on Termux with clang C compiler?

Thank you
Dmitriy

Is it possible to make libudev-zero work with bluez or maybe develop some instructions to work it around? Bluetoothctl is unable to find any bluetooth controllers.

Since libudev-zero uses pthreads, the .pc file should probably have Libs.private: -lpthread added, so that something that doesn't otherwise link libpthread (on platforms where libpthread is actually separate from libc, unlike with musl) will still get the symbols needed when statically linking libudev.a.

The readme states that PipeWire doesn't work without the patch, but there's another workaround.
Defining alsa sinks and sources manually allows you to use the PipeWire.
In pipewire.conf there's an example for source:

    # This creates a single PCM source device for the given
    # alsa device path hw:0. You can change source to sink
    # to make a sink in the same way.
    #{ factory = adapter
    #    args = {
    #        factory.name           = api.alsa.pcm.source
    #        node.name              = "alsa-source"
    #        node.description       = "PCM Source"
    #        media.class            = "Audio/Source"
    #        api.alsa.path          = "hw:0"
    #        api.alsa.period-size   = 1024
    #        api.alsa.headroom      = 0
    #        api.alsa.disable-mmap  = false
    #        api.alsa.disable-batch = false
    #        audio.format           = "S16LE"
    #        audio.rate             = 48000
    #        audio.channels         = 2
    #        audio.position         = "FL,FR"
    #    }
    #}

So you can have a sink (and hence some sound) by adding a few lines beside it:

    { factory = adapter
        args = {
            factory.name           = api.alsa.pcm.sink
            node.name              = "alsa-sink"
            node.description       = "PCM Sink"
            media.class            = "Audio/Sink"
            api.alsa.path          = "hw:0" # or whatever device number you have in your alsamixer
            api.alsa.period-size   = 1024
            api.alsa.headroom      = 0
            api.alsa.disable-mmap  = false
            api.alsa.disable-batch = false
            audio.format           = "S16LE"
            audio.rate             = 48000
            audio.channels         = 2
            audio.position         = "FL,FR"
        }
    }

Unmuting the device every reboot is also a thing that is required. You can nicely do it in the same config just below in the context.exec section:

context.exec = [
    # ...
    { path = "/usr/bin/amixer" args = "set -q -c 0 Master 100 unmute" }
]

Not the prettiest workaround, but I think it's worth mentioning.

I'm wondering what the purpose of this is over something like mdevd, are they complimentary or would I choose mdevd or libudev-zero ?

Another question, I need to install libgudev for another software, can I compile this against libudev-zero so I don't actually have to install udev?

When dhcpcd is started by the runit (busybox init) service, it says no valid interfaces found and just stops there, the service has to be restarted manually for it to detect my wifi adapter, but this is not the case with eudev:

no such user dhcpcd
dhcpcd-9.4.0 starting
dev: loaded udev
DUID 00:01:00:01:27:5e:0a:a4:d0:39:42:49:f3:14
no valid interfaces found
no interfaces have a carrier

I'm not sure if this is directly related to libudev-zero, but might be related to dhcpcd starting before mdev is initialised, any ideas ?

/dev/input/event10 is touchpad but due to bug is being treated as tablet

Xorg log:
http://0x0.st/-BKh.log

evemu-describe:
http://0x0.st/-BPL.log

udev internal properties:
http://0x0.st/-BPu.txt

possible buggy code:

I compiled and installed the library on my system and found that printing no longer worked. This is because my printer is USB and libusb fails, complaining about the lack of version information in libudev.
(Similarly, gparted will not run, with the same issue. Both CUPS and gparted work with no libudev installed.)

Not exactly sure what the issue is with pipewire; initial device enumeration here works but later down the line they all get rejected.

I have a PinePhone that has volume buttons as one device an a power button as another. They should be treated as keyboards so they can be associated with XF86AudioLowerVolume, XF86AudioRaiseVolume and XF86XK_PowerOff.

Proposing to revert e23633e. The commit message didn't go into detail about what kinda of device it was trying to fix so don't know if such devices exists or this was just a theoretical fix. I can confirm that the range we iterate over from [KEY_ESC, BTN_MISC) contains KEY_VOLUMEDOWN, KEY_VOLUMEUP, KEY_POWER. Haven't looked into exactly what key bits are directly detected for my device, but can confirm that reverting e23633e fixes the problem.

As I understand it, one intended use case of libudev-zero is to run programs compiled with udev without recompiling. However, it seems to also be possible to compile programs with libudev-zero and run with udev, or at least that is implied by

I am considering proposing the replacement of eudev with libudev-zero, at least as the default option, in Alpine Linux and possibly other (mostly musl-based) distros. For this, it would be easier if this support can be expected to continue in the future? I understand that no definitive guarantees can be made, since the upstream udev API may change, but a statement of "yes, this case is intended to work and I currently hope to keep it that way in the future" would be greatly appreciated.

Thanks!

Right now when using some libraries like libusb, the dynamic linker would complain about missing version symbols (but the program still works fine). For example when using adb:

$ adb
adb: /usr/lib/libudev.so.1: no version information available (required by /usr/lib/libusb-1.0.so.0)
Android Debug Bridge version 1.0.41
Version 31.0.2-android-tools
Installed as /usr/bin/adb

I'm not sure how libudev-zero map to systemd versions, but if we can add a file like this https://github.com/systemd/systemd/blob/main/src/libudev/libudev.sym and using it when linking we can get rid of the warning.

The method udev_device_get_sysattr_value truncates the return value at '\n' which breaks USB/IP because /sys/devices/platform/vhci_hcd.0/status has multiple lines.

The udev implementation returns the entire content instead (with a maximum size of 4MiB).

With the following change, USB/IP started working.

diff --git a/udev_device.c b/udev_device.c
index 92c1a41..15a8e0b 100644
--- a/udev_device.c
+++ b/udev_device.c
@@ -247,7 +247,7 @@ const char *udev_device_get_sysattr_value(struct udev_device *udev_device, const
         return NULL;
     }

-    if ((pos = memchr(data, '\n', len))) {
+    if ((pos = memchr(data, '\0', len))) {
         len = pos - data;
     }

I think reading the entire file as udev does would be the correct solution.
Please let me know if my thinking is correct or if I'm missing something.

So all my devices are detected and function normally when they are known upon starting X. However, if I attempt to hot plug a device, it is not recognized. Similarly, when I unplug a device, X doesn't notice its disappearance. Restarting X allows the new devices to be correctly detected, so seems like an issue with hotplugging.

I'm using the uevent method. I'm using a custom device manager, but it is similar to smdev. And in regards to uevent files, the same as the helper scripts provided in that it just dumps the environment to /tmp/.libudev-zero/uevent.XX. The uvent files are generated correctly. I also using the provided uevent helper scripts to no avail.

I'm using the latest libudev-zero (6685cfa). Made sure I was at the latest version of recompiled libinput and xf86-input-libinput. Also undid any patches I made to X.

Interestingly enough, I have Xorg in debug mode and I see messages like input-thread: InputThreadDoWork waiting for devices when I unplugging/re-plugging devices

Having a weird issue running libudev-zero with mdev

• Run startx
• Switch to tty2, run killall X:
  • if libudev-zero is used, X is killed and nothing more happens, if you try to switch to tty1 (alt + left arrow), input gets stuck completely, have to hard reboot
  • if eudev is used, X is killed and I'm thrown to tty1, input keeps working and startx can be run again

~/.xinitrc

feh --bg-center ~/dwm_nord.png &
slstatus &
exec dwm

Xorg log after killing:
libudev-zero
eudev

[    90.138] (II) UnloadModule: "libinput"
[    90.146] (II) NVIDIA(GPU-0): Deleting GPU-0
[    90.147] (II) Server terminated successfully (0). Closing log file.

These lines seem to be missing from the log when libudev-zero is used, maybe something needs to be done to mdev.conf ? The only thing I've done is add SUBSYSTEM=input;.* root:input 660 *env > /tmp/.libudev-zero/uevent.$$ to the existing mdev.conf. I'm on proprietary nvidia drivers if that helps.

Thanks!

After commit 496291 both hotplug and coldplug are broken. Uevents are created properly with proper permissions but xorg doesn't detect input devices at all.
UPD: it doesn't work unless i explicitly specify UDEV_MONITOR_DIR environment variable
UPD2: the exact source of error is line 258: for some reason it is expected that current user can write to UDEV_MONITOR_DIR. If i remove W_OK from access(), input detection works again

Since this is a drop-in replacement for libudev/libeudev, should I purge libudev/libeudev before installing this on the system?

The problem is that Devuan seems to heavily depend on libeudev, and purging it will purge fudamental parts of the system too:

The following packages will be REMOVED:
  apt* apt-transport-https* apt-utils* d-shlibs* dmsetup* eudev* fuse* i2c-tools* init* initramfs-tools* initramfs-tools-core*
  libapt-pkg6.0* libdevmapper1.02.1* libeudev-dev* libeudev1* libfido2-1* libparted2* libpci3* libusb-1.0-0* mount* ntfs-3g*
  openssh-client* openssh-server* openssh-sftp-server* parted* pciutils* rpi-eeprom* rpi-eeprom-images* sysvinit-core* usbutils*
  util-linux*

So, any notes on how to proceed in this case?

A quick attempt to build this on macOS reveals that it unconditionally includes Linux-only headers.
Is it possible to fix it?

/opt/local/var/macports/build/_opt_svacchanda_SonomaPorts_devel_libudev-zero/libudev-zero/work/compwrap/cc/usr/bin/clang -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -arch arm64 -std=c99 -fPIC -pthread -D_XOPEN_SOURCE=700 -Wall -Wextra -Wpedantic -Wmissing-prototypes -Wstrict-prototypes -Wno-unused-parameter -c -o udev_monitor.o udev_monitor.c
In file included from udev.c:20:
./udev.h:23:10: fatal error: 'sys/sysmacros.h' file not found
#include <sys/sysmacros.h>
         ^~~~~~~~~~~~~~~~~
In file included from udev_list.c:21:
./udev.h:23:10: fatal error: 'sys/sysmacros.h' file not found
#include <sys/sysmacros.h>
         ^~~~~~~~~~~~~~~~~
udev_monitor.c:22:10: fatal error: 'linux/netlink.h' file not found
#include <linux/netlink.h>
         ^~~~~~~~~~~~~~~~~
1 error generated.
1 error generated.
1 error generated.
udev_device.c:24:10: fatal error: 'linux/input.h' file not found
#include <linux/input.h>
         ^~~~~~~~~~~~~~~
make: *** [udev_monitor.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [udev.o] Error 1
make: *** [udev_list.o] Error 1

Hi, working on an Alpine package :

ElektraInitiative/libelektra#4247

When installing the APK on Alpine 3.12 armv7 :

~/MR33542_armv7/packages/testing/armv7 # apk add --allow-untrusted elektra-0.9.9-r0.apk
fetch https://dl-cdn.alpinelinux.org/alpine/edge/main/armv7/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/edge/community/armv7/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/edge/testing/armv7/APKINDEX.tar.gz
ERROR: FDB format error (line 29629)
(1/15) Installing libudev-zero (1.0.1-r0)
ERROR: libudev-zero-1.0.1-r0: trying to overwrite usr/lib/libudev.so.1 owned by eudev-3.2.9-r3.
(2/15) Installing http-parser (2.9.4-r0)
(3/15) Installing libssh2 (1.10.0-r2)
(4/15) Installing libgit2 (1.4.2-r0)
(5/15) Installing libelektra (0.9.9-r0)
(6/15) Installing elektra-dump (0.9.9-r0)
(7/15) Installing elektra-list (0.9.9-r0)
(8/15) Installing elektra-spec (0.9.9-r0)
(9/15) Installing elektra-sync (0.9.9-r0)
(10/15) Installing elektra-resolver_fm_hpu_b (0.9.9-r0)
(11/15) Installing elektra (0.9.9-r0)
(12/15) Purging eudev (3.2.9-r3)
(13/15) Purging udev-init-scripts (33-r1)
(14/15) Purging eudev-libs (3.2.9-r3)
(15/15) Purging kmod-libs (27-r0)
Executing busybox-1.32.0-r0.trigger
Executing elektra-0.9.9-r0.trigger
elektra: Switching default resolver to resolver_fm_hpu_b
elektra: Switching default storage to dump
1 error; 187 MiB in 912 packages

Then this happens :

Error loading shared library libudev.so.1: No such file or directory (needed by /usr/lib/libnm.so.0)
Error relocating /usr/lib/libnm.so.0: udev_device_get_parent: symbol not found
Error relocating /usr/lib/libnm.so.0: udev_device_get_property_value: symbol not found
Error relocating /usr/lib/libnm.so.0: udev_new: symbol not found
Error relocating /usr/lib/libnm.so.0: udev_ref: symbol not found
Error relocating /usr/lib/libnm.so.0: udev_device_unref: symbol not found
Error relocating /usr/lib/libnm.so.0: udev_unref: symbol not found
Error relocating /usr/lib/libnm.so.0: udev_device_new_from_subsystem_sysname: symbol not found

Your thought on this ? Would a symlink help ?

Regards

Can you make a proper new release for such a great library?

Hey there,

I stumbled upon libxdev from NetBSD, and I was wondering how does it compare with libudev-zero?

Thanks in advance!

solid has references to undefined symbols when using libudev-zero instead of udev. The issue appears when building baloo. Here is the build log.

I also expect a similar problem to appear with the programs which rely on solid; this list (and their respective build logs) includes:
kdelibs4support (here)
kio (checking)
plasma-desktop (checking)
plasma-integration (checking)
plasma-workspace (checking)

Normal pkgconfig files have the following format:

prefix=/usr
exec_prefix=/usr
libdir=${exec_prefix}/lib
includedir=${prefix}/include

This one is lacking the prefix variable which interferes with OpenWrt (we need to override the prefix).

% usbip list -l
 - busid 1-1 (1050:0407)
   Yubico.com : Yubikey 4/5 OTP+U2F+CCID (1050:0407)

 - busid usb1 (1d6b:0002)
   Linux Foundation : 2.0 root hub (1d6b:0002)

 - busid 1-3 (8087:0a2a)
   Intel Corp. : Bluetooth wireless interface (8087:0a2a)

 - busid usb1 (1d6b:0002)
   Linux Foundation : 2.0 root hub (1d6b:0002)

 - busid usb1 (1d6b:0002)
   Linux Foundation : 2.0 root hub (1d6b:0002)

usbip: error: problem getting device attributes: No such file or directory

Here's a minimal reproduction of the enumeration and filtering that usbip does:

#include <stdio.h>
#include <libudev.h>

int main(void)
{
	const char *path;
	struct udev *udev = udev_new();
	struct udev_enumerate *enumerate = udev_enumerate_new(udev);

	udev_enumerate_add_match_subsystem(enumerate, "usb");
	udev_enumerate_add_nomatch_sysattr(enumerate, "bDeviceClass", "09");
	udev_enumerate_add_nomatch_sysattr(enumerate, "bInterfaceNumber", NULL);
	udev_enumerate_scan_devices(enumerate);

	struct udev_list_entry *devices = udev_enumerate_get_list_entry(enumerate);

	struct udev_list_entry *dev_list_entry;
	udev_list_entry_foreach(dev_list_entry, devices) {
		path = udev_list_entry_get_name(dev_list_entry);
		puts(path);
	}

	udev_enumerate_unref(enumerate);
	udev_unref(udev);
}

Here's the diff between this program when linked against systemd's udev, versus libudev-zero:

--- /dev/fd/63  2021-10-29 11:33:59.551268883 +0000
+++ /dev/fd/62  2021-10-29 11:33:59.551268883 +0000
@@ -1,3 +1,10 @@
+/sys/devices/pci0000:00/0000:00:14.0
+/sys/devices/pci0000:00/0000:00:14.0
+/sys/devices/pci0000:00/0000:00:14.0/usb1
+/sys/devices/pci0000:00/0000:00:14.0/usb1
+/sys/devices/pci0000:00/0000:00:14.0/usb1
+/sys/devices/pci0000:00/0000:00:14.0/usb1
 /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1
 /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2
 /sys/devices/pci0000:00/0000:00:14.0/usb1/1-3
+/sys/devices/pci0000:00/0000:00:14.0/usb2

I think the problem is that usbip attempts to filter out the parent directories with its nomatch filters, but in libudev-zero, parent devices are added unconditionally, without filters being applied to them, so they show up regardless and confuse usbip.

networkmanager desperately wants to use it.

grepping through the source code and I don't see anything else in nm missing in libudev-zero, just this.

Hotplugging stopped working on sway recently, probably after update to 1.0.0 on AlpineLinux.
Uevents are correctly created, but sway doesn't detect new devices.
UPD after quick look on the latest commits: so now we have "fileless" netlink-based hotplug. It means that the old method through /tmp/.libudev-zero will no longer work.

When compiling libgudev errors ensue, owing I think to libudev-zero.

gudev/gudevdevice.c: In function 'g_udev_device_get_usec_since_initialized':
gudev/gudevdevice.c:1283:10: warning: implicit declaration of function 'udev_device_get_usec_since_initialized'; did you mean 'g_udev_device_get_usec_since_initialized'? [-Wimplicit-function-declaration]
1283 | return udev_device_get_usec_since_initialized (device->priv->udevice);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| g_udev_device_get_usec_since_initialized
CCLD libgudev-1.0.la
GISCAN gudev/GUdev-1.0.gir
/usr/lib/gcc/x86_64-ent-linux-gnu/10.2.0/../../../../x86_64-ent-linux-gnu/bin/ld: ./.libs/libgudev-1.0.so: undefined reference to `udev_device_get_usec_since_initialized'
collect2: error: ld returned 1 exit status
linking of temporary binary failed: Command '['/bin/sh', './libtool', '--mode=link', '--tag=CC', '--silent', 'gcc', '-o', '/setup/builds/libgudev-234/tmp-introspect5u81pmyr/GUdev-1.0', '-export-dynamic', '-g', '-O2', '/setup/builds/libgudev-234/tmp-introspect5u81pmyr/GUdev-1.0.o', '-L.', 'libgudev-1.0.la', '-lgio-2.0', '-lgobject-2.0', '-Wl,--export-dynamic', '-lgmodule-2.0', '-pthread', '-lglib-2.0']' returned non-zero exit status 1.

Would you say so?

Thank you for libudev-zero!

The following happens with sway 1.5 and wlroots 0.11.0. It happens sometimes, but not everytime.
When I do 'pkill sway' it crashes with a segfault when switching back to tty and leaves the computer in a unresponsive state. No more keyboard input is possible. However I can ssh into that machine and do a reboot. This way I will try to get some information through gdb soon.

Hello @illiliti

I found this project only after a few days experimenting with UDEV alternatives, which took me to BusyBox's MDEV, which in turn lead me to a libudev alternative to use along with MDEV.. and here I am.

I have just cloned the repo, and will build this piece of software today.

Just wanted to express how important this is: UDEV is now compromised because of the user-hostile people and model behind it's development (and it's now forced dependency on SystemD), EUDEV is dead... and libudev needs one or the other, so this project needs to live on so MDEV can be a libudev alternative in the future.

Thanks for trying, thanks for fighting these SystemD/UDEV anti-user corporations.
This is not an issue and can be closed. Just wanted you to know that I know.