sortie wrote:
I think it is more valuable to have example code, rather than code that can be combined into your kernel. I would be happy to see well-documented and simple-to-understand example drivers for common hardware.
That is exactly what would be awesome. Preferably in form of simple kernels (one per hardware or even hardware function) that demonstrate the exact sequence of finding, initializing/preparing/configuring and then using the hardware.
Most manuals or specifications of hardware don't make that very clear the seem like an overview of the hardware itself (i/o registers, i/o memory, etc.) without any hints about what needs to be done to do task X. Then it is mostly trial and error until you found out which registers need to be set in which order with whatever values or it's wading through several K LOC of other peoples code to extract the relevant parts.
Partially the Intel manuals are very good in that regard, e.g. the sequence for mode switching is explained very well, also other things. Other manuals would literally explain you:
There is a register named CRO. It contains flags: ... PE flag ... Then several pages later: There is a lgdt instruction it loads a gdt ... then even more later: There is a far jmp instruction ...
and from this you are expected to extract:
Intel Manual wrote:
[...]
2. Execute the LGDT instruction to load the GDTR register with the base address of the GDT.
3. Execute a MOV CR0 instruction that sets the PE flag (and optionally the PG flag) in control register CR0.
4. Immediately following the MOV CR0 instruction, execute a far JMP or far CALL instruction. (This operation is typically a far jump or call to the next instruction in the instruction stream.)
[...]
Anyway not wanting to hijack this thread, but pre-made black box drivers people can just use is one thing however actually explaining how and why stuff is done in the specific order is another. And I think the later is much more important than to provide free ready to use drivers as you can always copy from a big name open source operating system.
Also the problem with a unified driver architecture is that I don't think it will work, because you got so many different goals: simplicity vs. extensibility, security vs. performance, kernel mode vs. user mode drivers, etc. Those are all different concepts which can not be combined into one interface.
But anyway I think the most aid to hobbyists will be easy to understand drivers that explain the concept of how to interface with the given hardware well. If done right this makes it a no-brainer to port the functionality over.