OSDev.org

Hello,

I have an open source project called Open kernel parts.

Maybe you want to consider using the CDI interfaces (git repository) for the driver part? Your approach looks relatively similar.

Also, the license of the code is unclear to me, so I wouldn't use any of this is my kernel. You probably want to add license notices in each file.

Ok, I want to see if people are interested in it. The license will be BSD or MIT

A repo with portable drivers using standardized interfaces is a good thing in general. Standardisation is however the typical issue - there's UDI, CDI, and EDI around in the hobby scene, and everyone seems to have some sort of preference for various reasons...

I know about those interfaces.

I don't think there's a contradiction. If you're talking about malloc(), you're reusing an interface that is defined by the C standard library. You merely add the implementation. This is a good thing and makes your code more widely reusable. You can do the same thing in other areas by adopting interfaces already used elsewhere and providing your implementation for them.

For example, if you decided to use the CDI interfaces for drivers, the additional benefit that okp would bring in would be that it doesn' t only give you the drivers and the interfaces (that's the part that CDI does), but it also gives you an implementation of these interfaces so that it runs out of the box.

Combuster wrote:standardized [...] Standardisation

I like the irony of doing this with exactly this word.

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.

Well if people contribute the code will change to work with everybodies kernel.

TSilviu wrote:Well if people contribute the code will change to work with everybodies kernel.

Not unless everybody makes the same kernel. Since everybody is making there kernels in different ways, different structures there won't be code that will work unmodified for everyone. A better approach would be to provide samples that describes the concepts and theory behind different functions, like context switching and such.

As always, the truth is somewhere in the middle.

If you want to learn about something, sure, you need explanations and possibily examples rather than code for copying. But there are parts that, while I do know how to implement them in theory, like say malloc(), printf() or the string functions, I simply can't be bothered to implement them myself. They are boring, why should I waste my time with them when I can get full implementations? The same applies to drivers, after the third netword driver it really becomes tiresome and for the fourth one I want something that just works when dropped in.

Of course, the code that I take must be designed with a goal of accommodating different kinds of OSes, so that it will fit in my design. This is the tricky part when writing such code.

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.

Kevin wrote:Of course, the code that I take must be designed with a goal of accommodating different kinds of OSes, so that it will fit in my design. This is the tricky part when writing such code.

Yes. That's why I think it is important to write easily understood and portable code instead of black box driver ... also don't misinterpret that as you can't have both. Easily understood and portable black box drivers would be awesome, because that would make everyone happy. The ones that just want to use the drivers, the ones that have special needs with their drivers (security, performance, written in an obscure language) and the ones that just want to learn how the hardware is to be interfaced with.

So @TSilviu and all the others don't take my comments as discouraging but rather as a suggestion to incorporate more documentations, comments and make the code more simple, because there are enough open source drivers around that you can (with granted some effort) adapt to your own OS, but there is nothing that will sort of guide you to your own driver that you fully understand. The whole c'n'p driver thing has just a bit of too much negative connotation for me as I want to develop my own system and not just use someone else's. Again don't take that as an attack against your idea. It's just food for thought.

Hope this clears out some things.

Combuster wrote:A repo with portable drivers using standardized interfaces is a good thing in general. Standardisation is however the typical issue - there's UDI, CDI, and EDI around in the hobby scene, and everyone seems to have some sort of preference for various reasons...

Obligatory image:

osdog wrote:So @TSilviu and all the others don't take my comments as discouraging but rather as a suggestion to incorporate more documentations, comments and make the code more simple, because there are enough open source drivers around that you can (with granted some effort) adapt to your own OS, but there is nothing that will sort of guide you to your own driver that you fully understand.

I totally agree with you in theory. But in practice we all prefer hacking on code rather than writing documentation. So what happens is quite natural...

Also, re "some effort": Have you ever tried porting a Linux driver? In most many that would require a bit more than just some effort. Oh, and it's GPLed, while many people don't want to use the GPL for their OS.

The whole c'n'p driver thing has just a bit of too much negative connotation for me as I want to develop my own system and not just use someone else's. Again don't take that as an attack against your idea. It's just food for thought.

Let me guess: Your OS doesn't have more than a handful of drivers yet. Because soon you'd realise that drivers are not where you can be creative and where your OS could try doing things differently. Drivers are just stupid boring work. You should have written a few to know how it works, but certainly not for every single piece of hardware that you want to be supported eventually.

Sharing code with other projects for boring standard parts is a good thing and an important reason for the strength of open source. (Which is also why I recommended using an existing interface for the drivers, seeing that he's not really doing anything different from CDI here.)