Topic: [Linux] Beneficial endeavors to remove udev
This thread is primarily about my endeavors to remove udev from my Artix Linux install, but the outlook is intended to help Hyperbola (among potentially others) achieve similar.
(While I don't intend on installing Hyperbola (primarily because partitionless-EXT4: [mkfs.ext4 -FL Label -b 4096 /dev/sdx] is FAR too reliable for me to attempt anything else), I do have stars in my eyes for the project)
Disclaimer: This thread may occasionally go off topic due to the vast amount of coverage with the sheer knowledge involved with a project like this, and this post may also change (for the better) since I'm just bad at writing. ![]()
Future: I do intend to cover the history and motivations behind my decisions that lead me down such a painful path, but that's it's own can of worms regarding how much Linux has further devolved into a cloud-focused insecure monolithic abomination that's done nothing but abuse me since I started using it in 2012 after my primary WinXP (an OS which I still use to date) install corrupted itself ![]()
My personal goal is to have minimal static device configurations within initrd for setting up what udev would otherwise detect and configure, which from what I need really only needs to mount the mouse and network devices (if that) to a common location, as anything else I can mount after login...
(Ultimately I intend to remove my init system (OpenRC) entirely to have nothing at all running as root, but that's a goal for potentially another thread if Hyperbola is interested in providing similar options)
My current solutions to many various issues with this approach is simply just configuration scripts run from a custom user-level service daemon after login... (Although I AM building software to ease the tediousness of everything)
If anything needs root, I'm prompted with a terminal window to grant root to... (at least I know for certain what's running as root and when, unlike with OpenRC which does a ton of stuff behind the scenes you'll only know about via reverse-engineering)
One such example is a custom memory manager that properly clears swap and caches [echo 3 > /proc/sys/vm/drop_caches] to avoid Linux becoming sluggish when disk-cache would fill up the remaining unused RAM...
(I used to clear it every 10 seconds which worked quite nicely, but Wine would have problems finding my nvidia GPU (yet another thing to fix), so I reduced it to every minute as a workaround, which causes tolerable instability)
But regardless, that's getting off topic... ![]()
The first major hurdle to removing udev was Xorg and libinput, which was, despite the tediousness, actually quite easy to do...
All you need to do for xorg is remove the extension modules for libinput and libevdev, but additionally ensure you have the extension modules installed for the mouse and keyboard directly
The rest is just ensuring those devices are configured in Xorg.conf
The keyboard is extremely easy to configure, as the extension (if not Xorg itself) primarily gets that from the TTY (via the launch command [Xorg -nolisten tcp :0 vt1 -keeptty ...]):
Section "ServerLayout"
...
InputDevice "Keyboard0" "CoreKeyboard"
...
EndSection
...
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection(Bonus info, joystick, wacom, and even hyperpen and wiimote are also supported by Xorg directly with extensions, which not many seem to know about)
The mouse however... what little info I found about mounting the mouse via [mknod /dev/input/mice c 13 63] has failed to work, and I have yet to find any info that does
I assume a similar approach would be used to mount network devices, but I need some help figuring that out as [/sys/class/net/*] is empty without udev... >.>
IMPORTANT: Ensure your perms don't allow the user to freely read mouse/keyboard input, as that's the very reason why very many distros to date still run Xorg as root (ignoring the PE issues from doing so)
(Xorg should be ran as no more than user, or at least some mid-level group swapped to via newgrp, with the device nodes configured to allow Xorg to read them, but not the user, without granting full root access to Xorg)
But anyways, with Xorg out of the way, you should be able to remove udev without much issue...
The only thing that might stand in your way would be any packages depending on udev
dbus for example requires udev through libelogind, which obviously I don't have installed if I can remove udev XD
(The ONLY program I have that requires dbus at all is Nheko, which to make that work, I had to pack dbus into it's AppDir and run it with [dbus-run-session] which loads a shoddy script that runs a notification daemon and keepassxc under that)
So yeah, there ARE hurdles, but nothing too overly complex, especially if you focus on portability like I prefer (I guess it depends on what you prefer though, since I don't use a WM that can't live without dbus for example, heck I don't even use a login manager at this current moment) ![]()
I'll save the details of what I run for the history/pain thread, as I think it might already surprise a lot of people I even run Xorg ![]()