OSDev.org

Hi everyone, I'm new to this forum...
I'm trying to develop my own kernel, but I've run into a bit of a moral problem: device drivers/modules. I keep pondering on what to implement inside the kernel or in external modules...
I plan on detecting devices using ACPI and then loading device drivers for each device, as needed.
I don't know yet if ACPI detects PCI as a separate device or not... so would I go implementing PCI as part of the kernel or as a module (I'm thinking that not all PCI controllers use the same I/O ports for enumerating PCI devices so maybe each motherboard manufacturer would provide their own device driver).
I guess my real question is this: Has anyone here successfully used ACPI the way I described above? If so, then can you provide a dump or something to show the ACPI namespace on your test machine? All I really need is an example to get an idea of what this namespace looks like, and I'd hate to have to read the ACPI spec, because it has Microsoft's fingerprint all over it and it would take me a lot of time to figure out all the ambiguities. Google doesn't help much...

Oh, and I forgot what I was initially going to ask: Is there any standard open source model for device driver files or for loading/unloading device drivers?

Thanks,
Gabriel

zaleschiemilgabriel wrote:Oh, and I forgot what I was initially going to ask: Is there any standard open source model for device driver files or for loading/unloading device drivers?

Sarcastic answer: Whatever the latest Linux kernel says.

Serious answer: While there have been efforts to create a "standard" driver interface (UDI), this has effectively been shot down by the Free Software Foundation for "philosophic reasons" (if we don't control it by means of the GPL, it's evil). So, while there might be UDI and other projects, there is no de facto standard aside from... well, see sarcastic answer.

And I guess that whatever the linux kernel says is bound to the linux kernel?
What about ACPI? Is it worth supporting it in my kernel? Also, I could make my kernel ACPI-dependent or put it in a separate module and load it if I detect ACPI or fall back on legacy stuff if it's not present... My head is spinning. If the future says "go with ACPI", then that's the way I'll go, but if it's just another major screw up by Microsoft & friends, then I don't want it!

Hi,

Also have a look at > this article < which explains about an alternative (EDI). As you will see, the article is not impartial and I am not recommending either interface - just a FYI!

Cheers,
Adam

Thanks AJ, but unfortunately EDI doesn't help very much, as I am writing my kernel in assembly language. I suppose I could implement something standard over the top of what EDI is supposed to be, but that would just add overhead to the kernel. I'm trying to stay away from anything C/C++ related, as it adds a considerable speed deficit to assembly language.
On the other hand, this is just a hobby, so I guess it's no biggie if I put a bit of trust into EDI if it turns out to be what it says on the cover.

zaleschiemilgabriel wrote:I'm trying to stay away from anything C/C++ related, as it adds a considerable speed deficit to assembly language.

*ahem* careful...

Also, I could make my kernel ACPI-dependent or put it in a separate module and load it if I detect ACPI or fall back on legacy stuff if it's not present...

In an ideal world, yes, you would detect ACPI and if it's not there, fall back on legacy stuff. In the real world, however, if you have a hobby OS and you are the sole designer, whatever you code your kernel for now will probably be legacy by the time you finish anyway. I have taken the following approach: Code for the hardware I own at this moment - get it working on my machine and emulators but try to keep the kernel as extensible as possible (put a lot of thought in to the module interface).

Using that philosophy, if you have ACPI by all means *just* support ACPI, but by leaving your kernel as flexible as possible you can replace ACPI with whatever comes in the future by just plugging in that new module. Using this ethod, you can also add legacy support at a later stage, if your OS goes more mainstream and you have a team of hundreds of developpers

Cheers,
Adam

I'm trying to stay away from anything C/C++ related, as it adds a considerable speed deficit to assembly language.

This is an intervention. If you're thinking of replying to this quote, PLEASE DON'T - We've had too many anti-C/pro-C anti-C++/pro-C++ off-topic arguments recently, please just leave it and possibly refer the OP to a previous rant.

I still don't know what the ACPI namespace looks like. If nobody posts some kind of example I'll just have to find out for myself. I've already tested for ACPI support on my machine, so all I have to do is go into the tables, but I can't make heads or tails of the specs for ACPI.

Here's another question: Is it worth implementing ACPI support if all I really want to do is use PCI devices? Will ACPI be (better for) enumerating/configuring PCI devices or do I still have to use the PCI bus enumeration/configuration? From what I've read from the ACPI specs most of the "configuration" stuff there is for the power states.

It's weird that ACPI has been around for a while now, but the only thing that Google finds is either the ACPI website, the Wikipedia ACPI page, or something that is either a Linux or Windows problem. Even searching for images is useless...

zaleschiemilgabriel wrote:And I guess that whatever the linux kernel says is bound to the linux kernel?

Bound to the kernel, bound to change whenever the kernel maintainers feel like it, and most importantly, undergoing significant efforts of turning the kernel - driver interface into a GPL-only matter.

Solar wrote:Bound to the kernel, bound to change whenever the kernel maintainers feel like it, and most importantly, undergoing significant efforts of turning the kernel - driver interface into a GPL-only matter.

I don't think a hobby OS should be bound to any license. The developer(s) just do whatever they want with the code. I also don't care if hardware manufacturers ever decide to write drivers for my OS or if they abide by whatever license I impose on them. If Linux aims to be a completely free OS, including the drivers, that's their problem.
In a sentence: I don't care about licenses, so please don't bring that into discussion.

You asked whether there is a "standard" driver architecture. I answered that the only "standard" as in "mainstream" is the Linux kernel/driver architecture. You cannot discuss that without also discussing the license (unfortunately). If you think you can ignore the license attached to a piece of code because yours is a "hobby" OS, that's crossing a legal line, but that's up to you.

I'll shut up now.

I won't have to ignore any license because the code will be mine to begin with.
Since you started this, here's something for you to ponder: If a piece of code doesn't have any license attached to it does that mean that it's free or proprietary? Not everything needs a license, you know...

I don't quite get your meaning. If you want to adapt the Linux kernel/driver interface, you would do this so that Linux drivers could work on your kernel, right? This would be pretty hard to do without violating the GPL, IMHO. But let's not get into a detailed argument here.

As for your question. Strictly speaking, code that does not mention any license is copyrighted "all rights reserved" in most countries. That includes any code snippets that are posted on some forum, which is stupid of course, but many things in law are.

God, I wish I was dead.
REMINDER TO ALL: Please, if you can answer my question, do so. If you can't, don't go saying stupid things.

zaleschiemilgabriel wrote:I won't have to ignore any license because the code will be mine to begin with.
Since you started this, here's something for you to ponder: If a piece of code doesn't have any license attached to it does that mean that it's free or proprietary? Not everything needs a license, you know...

According to copyright law in most countries, A piece of work is "automatically" copyrighted and the author reserves all rights to the work.

See http://en.wikipedia.org/wiki/Berne_Conv ... stic_Works

Drop the "I'm going to ignore copyright!" B/S..

Respect authors rights