Hi,
Thanks for the answers! I think there's a misunderstanding on the goal of this project, I'll try to explain below.
alexfru wrote:
Do you consider the fact that a lot of folks have patchy understanding and handle of things like
No. I don't care what folks can't do. I'm interested in helping those who can. Developers with patchy understanding of those things wouldn't be able to write their OS, and no interface can help with that. They must learn and practice more, that's the only way. But beginners are not ODD's target audiance. It's aimed for advanced developers, who have implemented a lot already in their kernels, and now want to increase the number of supported devices.
alexfru wrote:
Implementing the building blocks isn't easy. Putting a system together using those blocks isn't easy either
No it is not. But easier than to get and read all hw specs and implement everything on your own. ODD does not provide ready-to-use building blocks btw, that's not the goal. It's just a recommendation on driver source interfaces. You definitely need to do some integration work in your kernel with that, but that's okay as ODD doesn't want to tell you how you should write your kernel or if you want async or sync calls or microkernel or monolithic kernel etc.
alexfru wrote:
One needs to do that while really understanding what they're doing, how the components work and interact with one another, etc.
That's why I'm aiming at a minimalistic approach. ODD does not care about the components nor how they interact, except for the lowest layer of the driver, but only at source compatibility level.
alexfru wrote:
What if they can't understand your code or satisfy its requirements because, well, they just aren't up to the task yet or they're doing something inherently incompatible with your code for one reason or another?
Then they won't be able to understand the hw specs and write their own drivers either. Simple as that. Again, ODD is not a complex code, just some definitions in a single C header. It's just an interface that encapsulates the lowest layer of the driver. By following it's recommendations and using it's typedefs, hobby OSes could exchange driver sources with minimal integration effort (but not with zero effort).
alexfru wrote:
IOW, what's your idea as to why there is a problem and what it is? Are you sure you aren't trying to help with the wrong thing?
Positive. I'm not trying to design a complex API, or binary compatible drivers or anything like that. I'm just suggesting a minimalistic source driver interface with some kernel hooks to make porting device drivers among hobby OSes easier.
Korona wrote:
One question that comes to mind is how to handle synchronous / asynchronous drivers?
Out of the scope. This spec is a lower layer than that. This only provides somewhat standardized way to read/write from a device, but it does not care when and how you call those. That's a higher abstraction level which I deliberatly don't want to address. The point is to create a simple interface for the drivers so that you can integrate them into your kernel more easily.
Korona wrote:
In addition to that, there needs to be some way to access hardware (e.g., to map MMIO regions from PCI BARs and/or legacy HW).
That's correct.
songziming wrote:
ODD spec is only good for big and complex devices, like graphics adaptor, network card, sound card, etc.
Exactly. Let's say you already have a networking stack but only one network card driver. With ODD, you can increase the number of supported network cards easily (but you have to have a networking stack, as ODD does not want to solve everything). Another example, you have implemented a GUI with shiny screen resolution chooser, but you have only one video card driver. With ODD, you can add more (but you have to have the GUI and screen resolution chooser as ODD does not provide those).
songziming wrote:
That also means we have to define a set of kernel API, just like ACPICA does.
Definitely not. ACPICA tries to solve all aspects and create fully functional driver ecosystem and therefore is very complex. ODD just tries to somewhat standardize driver interfaces to ease portability. Fundamentally different goals. But it is true that it requires some hooks from the kernel, but I definitely want to keep that as small as possible (4-5 functions tops).
I hope this makes it clear what ODD is and isn't. To sum it up, it's a C/C++ header file to provide a standardized driver API and interface to make porting drivers among hobby OSes easier. Nothing more, nothing less.
Cheers,
bzt