I did a lot of OS installs way back when hardware autodetection was in its infancy, and I think it's a luxury feature. It's very nice when you have a lot of installs to do on varied hardware, but it saves little when you're only installing on one machine. Are you testing your OS on many different machines at this stage in its development?
Interested people trying out your OS will only expect it to work where you say it works. If you say it only works on Qemu with certain options, that's what they'll use. (Unless they're crazy like me!
)
I recommend forgetting about autodetection for now, and focus on cleaning up your code instead. Otherwise, you're going to end up with many more situations like this:
Garnek0 wrote:
Rewriting the DAL is completely out of the question... doing that will create such a mess that i'd probably just end up git checkouting back to where i started.
I don't think this is sunk cost fallacy, (sorry @Octocontrabass,) but rather the fact that you know you don't have the skills needed to write clean code. (Am I right?) Focus on designing cleaner subsystems. The cleaner they are, the fewer impossible messes you'll get into. Note, though, that I write "clean
er", not "clean" -- don't try too hard. It's possible to make a design so pure, it creates more problems than it solves. Pure functional languages can have that problem.
Garnek0 wrote:
I tried looking at linux to see how it's implemented there but linux is so complicated that i couldn't even find the routines for the drivers.
Linux is the last place I'd look because it's so complex. It's insanely overoptimized and I gather that's not the only problem. You'd probably have an easier time reading decompiled Windows source -- don't do that!
OpenBSD source is known for being easier to read. Plan 9 & 9front are easier still.