OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 11:49 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Open kernel parts
PostPosted: Thu May 16, 2013 1:53 am 
Offline

Joined: Thu May 16, 2013 1:30 am
Posts: 5
Hello,

I have an open source project called Open kernel parts.


Last edited by cdos on Mon May 25, 2015 12:07 pm, edited 2 times in total.

Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 2:45 am 
Offline
Member
Member

Joined: Sun Feb 01, 2009 6:11 am
Posts: 1070
Location: Germany
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.

_________________
Developer of tyndur - community OS of Lowlevel (German)


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 3:02 am 
Offline

Joined: Thu May 16, 2013 1:30 am
Posts: 5
Ok, I want to see if people are interested in it. The license will be BSD or MIT


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 3:23 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
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...

_________________
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 3:37 am 
Offline

Joined: Thu May 16, 2013 1:30 am
Posts: 5
I know about those interfaces.


Last edited by cdos on Mon May 25, 2015 3:17 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 4:16 am 
Offline
Member
Member

Joined: Sun Feb 01, 2009 6:11 am
Posts: 1070
Location: Germany
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. :D

_________________
Developer of tyndur - community OS of Lowlevel (German)


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 5:11 am 
Offline
Member
Member
User avatar

Joined: Wed Mar 21, 2012 3:01 pm
Posts: 930
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.


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 6:09 am 
Offline

Joined: Thu May 16, 2013 1:30 am
Posts: 5
Well if people contribute the code will change to work with everybodies kernel.


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 6:59 am 
Offline

Joined: Wed May 15, 2013 1:07 am
Posts: 3
Location: Sweden
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.


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 7:24 am 
Offline
Member
Member

Joined: Sun Feb 01, 2009 6:11 am
Posts: 1070
Location: Germany
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.

_________________
Developer of tyndur - community OS of Lowlevel (German)


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 9:32 am 
Offline

Joined: Wed May 01, 2013 2:59 am
Posts: 19
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.


Last edited by osdog on Thu May 16, 2013 9:41 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 9:40 am 
Offline

Joined: Wed May 01, 2013 2:59 am
Posts: 19
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.


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 12:02 pm 
Offline

Joined: Thu May 16, 2013 1:30 am
Posts: 5
Hope this clears out some things.


Last edited by cdos on Mon May 25, 2015 3:18 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Thu May 16, 2013 3:36 pm 
Offline
Member
Member
User avatar

Joined: Sat Jul 30, 2011 10:07 am
Posts: 374
Location: Wrocław/Racibórz, Poland
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:

Image

_________________
Reaver Project :: Repository :: Ohloh project page
<klange> This is a horror story about what happens when you need a hammer and all you have is the skulls of the damned.
<drake1> as long as the lock is read and modified by atomic operations


Top
 Profile  
 
 Post subject: Re: Open kernel parts
PostPosted: Fri May 17, 2013 3:15 am 
Offline
Member
Member

Joined: Sun Feb 01, 2009 6:11 am
Posts: 1070
Location: Germany
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.

Quote:
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.)

_________________
Developer of tyndur - community OS of Lowlevel (German)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 24 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group