And my research respects that...

It would have to be translated though to whatever is changed in BSD as you may find some discrepancies there, though over all, what I'm doing doesn't go much farther than userspace...
Unless we're talking about that kernel module improvement I mentioned which puts device authority in it's rightful place... that would need a lot more work between multiple versions of both Linux and BSD, if a portable external module can't be achieved...
(there's also HAL which is shamefully being removed in newer kernels for some retarded reason) >:(

I may not be a kernel expert, but I do at least know about some of the hassles

But you do also have the Linux side of Hyperbola as well, which isn't exactly dead, and my research absolutely benefits

I did state that initially on the first line of the thread, basically, take my info and apply it where you can, because it's still a unix-like kernel. ;D

Thanks btw

Nevertheless it is not really helpful for Hyperbola as project when people use this forum alone as their personal report of experiences and leave the project itself aside. That really does not make much sense. Hope you are understanding this point.

I'm not one to stop looking just for the sake of the problem of complacency where nobody else is willing to look

It's only a matter of time until something IS figured out, and it would be nice if my freedom to note my inevitable findings wasn't stifled

I'm not sure if you have the ability to open, or if the decision around closing is designed to be final, but if the former is the case, would you please re-open my thread as I have a new lead I'd like to invoke the community (not limited to Hyperbola) look into.
(I know "community" is a far cry, but I'd like to be optimistic as I constructively bear down a bit on ye old ideology here) XD

Thank you

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?