The first thought is that we can go forward with smdev as the mdevd is mostly only for terminal-output and running. But for desktop-usage we need surely a bit more as otherwise the X-server won't startup correct.

X11 might not start up with auto-detection without a complicated device manager daemon, but it is trivial, with the kbd driver especially (evdev switches around the devices sometimes) to have a static xorg.conf which is plug-and-play. The question, I presume, is about making it accessible to the average user, in my humble opinion! :) It is already possible, on all the inits other than systemd that I know, for a power user to disable the udev service and manage his own devices and X configuration.
To have a plug-and-play general user experience with X like in *BSD, it can be experimented with whatever device manager currently provides that, I think. o7

BTW, there is no mdev process it is simply called as and when a device is connected/disconnected, does what it needs to do then exits.

I just want to note I missed this before from the thread I posted, yeah that's a semi-solution that absolutely helps, but a kernel module managing this as mentioned in my post before would still be more secure
(Attackers love the 1ms window made available to them, which is something that even Comodo HIPS would catch and Prevent on WinXP back in 2008 by haulting the attacking process)

EDIT: LOL that post was even made in 2013, which was around the time I started talking about this stuff XD
(You won't find anything because all of those efforts were either hidden or deleted, though I do have an image I could share about it from an AskUbuntu post about HIPS I caught in 2019 as it was being deleted)

I was trying to stay primarily on the topic of figuring out the udev problem, so sorry if I split off a bit there with acl and all that... XD

But anything to keep things clean while also spreading info I'm happy with! ;D

EDIT: After reading through a few times, I figured it was better to just remove that bit entirely, save it for another thread and all that, it's not much to miss out on

So I propose the following: When community-members have knowledge and findings, we can create a new thread with all that to find more easy in detail. If you find something being easily to be reproduced there is no need to "fork" this thread anywhere and it would be kind to share your findings. So my annotation about "not correct place" is only meant as friendly hint and help when something creates out of more so people can orient better. Is that okay for you?

https://forums.gentoo.org/viewtopic-t-9 … art-0.html

I'm actually looking to configure static devices like the mentioned old days as most of my hotplugging problems are already solved via a few sudo awk scripts (probably not the best idea to trust awk as root as it's not much different from python, but probably not too big of a deal as the scripts are only run-once)

But if any of you know of the old methods I could use to manually mount my network devices in [/sys/class/net/*], I think that info would benefit more than just me for those who'd similarly like to tackle static configurations while being unable to find relevant information

The implementation to be provided by the kernel module however I'd argue should be configurable...

While I'd personally prefer a custom syscall capable of being called from user-level that the kernel can verify (with user feedback? (RIP remote management likely)), devfs (or procfs (like nvidia) if preferred) can also work to satisfy the Unix philosophy (or at worst ioctl() like KVM does, amongst other device drivers), heck why not both XD

Just want to mention idk everything (nor am I a kernel dev), but you can tell I've been sitting on this stuff for a long time, since 2014 in fact, or at least when root-xorg really blew things out of the water that people still configure to date...
(could trigger everyone and mention sshd, tee hee, but regardless (not the point) the source again is still root, run everything user-space as user and you'll solve all problems regarding PE)

It is from our current point of research not fully possible to use Linux without a hotplug based daemon, to manage that events from the kernel.

I'm looking into removing udev from Linux as a whole (no alternative like vdev, smdev, or mdevd, just doing everything in initrd if not an external kernel module), and I feel like my research could potentially help benefit you guys as well

I've already gotten close enough to remove udevd entirely, including being able to load into an xorg desktop with keyboard control (no mouse as of yet)

But one major drawback I'm having is [/sys/class/net/*] is completely empty, which means udev is responsible for creating [eth0] and the like, and I'm having much trouble finding any information as to how to do that manually...

Similarly to the amount of trouble I'm having mounting mouse devices as well for xorg

Would any of you know anything in this area that might help?

It is NOT free from systemd, it is NOT free to be called as alternative. It is just a helper to simulate something being there. As long as those so-called "alternatives" are used the real problems are not possible to be seen. And one essential problem is that many calls around and in GNU/Linux are going with udev, which is essential part of systemd. There is no alternative implementation, it is just this. Same as with D-Bus and many others. There are "alternatives", but they have to follow the so-called standardized implementations. There is no different choice or other possible solution on that special road. And HyperbolaBSD won't have any "udev". So Hyperbola GNU/Linux-libre does not need it either.

There are surely variants like eudev for example giving the udev-version out and trying to backport functionalities towards existing implementations before udev was integrated into systemd in a whole. This may work for the time being and is some wrapper around. But the longer and newer implementations get the more problematic this is going. Also for Hyperbola with the current ideas within here as they are also partwise a wrapper with libudev-zero, which is a intermediate "library in the middle" for simulating. With our current way forward we will pay a price for sure and this means also especially going away from very centric applications and projects around Gnome and KDE. Those will stop working sooner or later for sure.

To underline: Not udev itself is going to be the problem besides being foremost only onwards GNU/Linux, but the inclusion of udev into systemd is the big elephant in the room. And with its exclusive integration systemd became also even more integral element. It is not just that Linux (with or without GNU) was designed in its roots that way, it was made that way over the course of corporations and companies doing that. And this way of forced adoption got that problems ahead. Exactly this, because maintainers of systemd said so often that nobody is forced to use systemd and now what? We all know that this phrase is just done out of convinience. Would systemd not be that much adopted? Well, working. Would systemd be adopted (which happened)? Well, you can always go for searching alternatives, but we are not responsible for you ending without updates or working tools. Yes, you are. Same as with the removal of 32bit. Is there a thought for people and states simplified not having the money to afford buying newest hardware? We are leaving really people alone with all of this. A minimalistic system, with the point of control by its users and developers together, not just one instance alone.

OpenBSD is not the only one we orient towards. But in general: "udev" is also a Linux-only one framework and included in systemd longer time ago. eudev was one project getting it single-sided back. But same as other approaches: All of them depend on upstream. There was never a hard fork done. So it is even more needed to get alternatives running with, either better portable or complete different.

Yeah, I suppose it is linux only, but I do recall it being free from systemd at one point. Still, if its linux only then you are right to do so.

On the other side there is mdev as said: https://skarnet.org/software/mdevd/
With: https://github.com/slashbeast/mdev-like-a-boss