More detailed info related to the mknod bit for mice
https://mkeys.sourceforge.net/input_setup.html

Localized code blocks just in case the link goes down (I'm tired of finding info that goes nowhere, so best not to add to that 10 years later)

Kernel modules required (compacted from the page):

    input.o - Input core (main driver)
    mousedev.o - If you need mouse support
    keybdev.o - If you need keyboard support (most likely you do)
    usbcore.o - For USB to work
    usb-[uoe]hci.o - USB host controller (either one: UHCI, OHCI, or the newest EHCI)
    hid.o - The HID driver handles all HID devices

    evdev.o - Needed for HIDNode driver to work

Standard devfs files those modules should provide:

    cd /dev
    mkdir input
    mknod input/mice c 13 63 # this is for USB mouse, if you own one

    mknod input/mouse0 c 13 32 # those are for applications that require
    mknod input/mouse1 c 13 33 # PS/2 - style mouse device
    mknod input/mouse2 c 13 34
    mknod input/mouse3 c 13 35 
    ...
    mknod input/mouse30 c 13 62 

    mknod input/event0 c 13 64 # this is for event devices required by HIDNode
    mknod input/event1 c 13 65 
    mknod input/event2 c 13 66
    mknod input/event3 c 13 67

I'll have to play around with these and make sure Xorg finds my mouse, next time I'm able to reboot

Disclaimer: So some might frown upon me for this, but I promise I'm not using it in any distasteful way...

I've gotten better help from a local AI (ran with llama-server loading a gguf) than I have from anywhere on the internet.
(Don't discredit my efforts just because I'm using AI please, I'm more than aware AI is 99% incorrect, and haven't trusted it since the birth of ML)

What AI told me that the internet couldn't, is allegedly, mounting network devices only requires modprobe and ln, and all you need to do is search sysfs to find the folder ([/sys/devices/pci0000:00/_/_/net/*]) to ln to [/sys/class/net/*]...

Can anyone capable verify kernel modules actually create the [eth#]/[enp#s#] folder for me?

Seriously, how am I supposed to validate an AI isn't hallucinating if the internet isn't even willing to provide information about a particular topic...
It's really annoying there isn't any information about this... XP

That's exactly why I promised I'm not using it distastefully.

I get the concerns, and think I've more than spoken my distaste for AI with how inaccurate it is.

That's why I'm verifying, since the internet isn't of any help here.

Like I said in the other thread, it's just a lead.

EDIT: I wish I could react to your post with a 👍 because I absolutely agree, and wish it didn't have to come to this
Just goes to show how much we've fallen that I need to stoop to such levels just to get anywhere with my endeavors... u.u

EDIT2: I should probably add if you're not aware, when I say "local" I mean "offline", as there's no way I'm trusting that S with an internet connection.

Absolutely understandable (may as well have almost been no different from an ADDoS for you (or so I've heard stories of such scraping taking down websites anyways)), yeah Meta is disgusting, just like the rest of them, the only justification at all I see for using these stupid models is the scraped data that's no longer available on the internet, and the half of which that is, I can't even access due to those very restrictions (Anubis doesn't work for me on most sites because I refuse to accept the veil for future JS malware, if it isn't that already)

And that's also where search engines have become so bad (as per the agenda) they don't even list results for your prompt anymore.

regardless, yeah, I'm carefully reviewing what it tells me, which FYI, the particular model I'm using is a distill of GPT-5.2, just for context of where the above info is actually coming from (what you know about where they've scraped).

I really wish I could use something better, but such is the state of the current internet until every last one of these stupid data-centers falls.
And even then, there's no telling if the internet will ever be the same again, now that the damage has already been done... u.u

I note this here (again): Only post what you discovered your own, not throughout any kind of machine-learning. And no, you do not have to use that. You can also tryout different approaches, including perhaps also asking people being there using at a time before udev / eudev. I doubt that either people here reading current (me included) have that knowledge or others having that but not reading here. In sum this ends quite demotivating, but to be honest clear: We are a little circle of individuals and minor groups being interested in that. So we first need to recognize and second we then need different approaches.

Otherwise we would have been faster with solutions to replace udev / eudev fully. With the restriction also that the result is also different. But as noted: There are different ones like sinit and others. Besides also to note that removing udev or other replacements make also right more growing group of packages either being not possible to be used or only possible to be used with many patches incoming.

The questions in follow-up:

Is a modern called environment right away possible or just no longer wanted without udev?
Is a replacement development at all possible and at hand? Otherwise only possible towards which version of kernel and implementation?

And what about missing devices then? Or states used then and now? Rendering the further future useless at risk?

Please do not get me wrong, but at this point we can clearly enumerate the will of people also: There are really many, a big number of people, only claiming to be interested in alternatives. So when you need to use "AI" to enumerate others either may be able to help or can help with research, and they clearly do not raise their voices here or elsewhere (otherwise we would find it together) ... we see that this is a clear missing perspective of interest. What am I saying now with this? We two or more are interested, but when we need to use "AI" to give us hints where to look our base is not stable going. My proposal would be then: Either looking or approaching old documentations and then also people with that special experiences before udev-handling. Using "AI" is not a must and if there is nothing left to find it, then GNU/Linux is not interested and we should do this here for our own. And I'm really willing to support this research when the long list of packages is finished upcoming.