OSDev.org

Schol-R-LEA wrote:OK, then, that clarifies a lot. However, I think you'll find it difficult to abstract the hardware away before you implement either an abstraction layer, or the low-level drivers to fit into said layer; and if your goal is to have abstraction without a defined abstraction layer or interface, uhm... got nothin', sorry. I'd almost be tempted to recommend an exokernel approach, except that the necessary virtualization for an exokernel requires a lot of low-level work - and the whole idea of exokernels is to avoid abstracting the hardware, and instead have each 'application' basically be a slew of independent libraries, which is sort of at cross-purposes for what you seem to want.

No, well yes, but not really.. I'm not talking about such a high level of hardware abstraction.
I meant that I need those AHCI drivers so that I can implement things like fopen(), fread(), fwrite(). (file system is being worked on, but it's pointless if I can't even read from a drive) So right now I need to make the AHCI read/write work and the rest should be a "piece of cake", compared to this at least.

I'm talking about a level of abstraction allowing me to work with both PATA (for whatever the reason I might need that) and SATA (which is currently the huge problem as without it I can't run my OS on any real hardware) drives.
I'm not looking for any magical hardware abstraction, I just want to avoid working directly with ports. Which is what I need the AHCI driver for, which I would have had if I could get the read() function to work and then somehow figured out write() function. I currently believe that I shouldn't need much more than that, I'm just unsure how difficult that might be.

As I've said, I've mainly developed Windows .NET applications until very recently, except for a couple of microcontroller applications at school. That's why I have such a problem with the hardware, because I haven't worked with it.

Just a small note on those specifications and data sheets: I feel that there are many OS dev beginners that are intimidated by technical specifications. Yet reading and understanding such specifications makes up a huge part of driver development. If you want to develop drivers for modern hardware you have to get used to specifications. There are no simple tutorials that tell you how to write a driver for modern graphics cards, ethernet cards, USB or IEEE 1394 host controllers and most other modern devices.

Nobody takes delight in reading through the ACPI, UEFI or XHCI specifications yet it has to be done if you want an OS that supports those features/devices.

Korona wrote:Just a small note on those specifications and data sheets: I feel that there are many OS dev beginners that are intimidated by technical specifications. Yet reading and understanding such specifications makes up a huge part of driver development. If you want to develop drivers for modern hardware you have to get used to specifications. There are no simple tutorials that tell you how to write a driver for modern graphics cards, ethernet cards, USB or IEEE 1394 host controllers and most other modern devices.

Nobody takes delight in reading through the ACPI, UEFI or XHCI specifications yet it has to be done if you want an OS that supports those features/devices.

Except that I don't want to use graphics card, network card, USB, USB 3, or anything else like that.
I want a very basic thing, simple AHCI drive support.
And yes, it truly is a huge burden to go through hardware documentation, especially for people who don't care about the hardware itself.

I want a very basic thing, simple AHCI drive support.

It is not simple to get support for AHCI. Why do you think your having so many issues with the code you've copied? It's example-skeleton code, which - if you are lucky - barely works (When the stars align properly and the weather conditions are correct, the example code from wiki might work).

If you do want an AHCI driver that works - you need to code one from scratch. End of story. There is no library in existance today as - I repeat - drivers are highly OS-specific.

MollenOS wrote:It is not simple to get support for AHCI. Why do you think your having so many issues with the code you've copied? It's example-skeleton code, which - if you are lucky - barely works (When the stars align properly and the weather conditions are correct, the example code from wiki might work).

If you do want an AHCI driver that works - you need to code one from scratch. End of story. There is no library in existance today as - I repeat - drivers are highly OS-specific.

They don't have to be. What exactly would such a driver depend on, huh? The AHCI driver doesn't make use of any OS-related calls.
What do you mean by aligning start and what conditions are you talking about? There isn't mentioned anything about that on the Wiki.

natiiix wrote:What exactly would such a driver depend on, huh?

Memory allocation, interrupt allocation, ABI, registers reserved by OS, library format, operating system functions required (for example to print error messages), etc., etc.

Huh.

iansjack wrote:Memory allocation, interrupt allocation, ABI, registers reserved by OS, library format, etc., etc.

Memory allocation isn't necessary for this particular driver, interrupts are nowhere to be seen in the example on Wiki, no idea what ABI is, no such thing as reserved registers, no idea what library format means... Yeah, pretty good points you're making there.

The points I am making would probably make more sense if you understood them.

iansjack wrote:The points I am making would probably make more sense if you understood them.

Or perhaps if they were valid. You can easily make drivers with an easy to use API for the vast majority of devices. And that's exactly what I want.

natiiix wrote:You can easily make drivers with an easy to use API for the vast majority of devices.

If it's that easy, just do it.

iansjack wrote:If it's that easy, just do it.

I don't think you quite get it.
It's easy to do when you know how to make drivers to begin with, which can't be done when no one is able to tell you how.
And it definitely is easy to make them OS-independent which I would have proven if someone were to help me find the problem.

It even easier to say something is easy when you have no idea what you are talking about. The proof that it isn't easy - or that there is no need for it - is that no-one has managed - or bothered - to do it. Don't pontificate about how easy it is when it is far beyond your capabilities.

I don't think OS development is your thing.

I don't think there's much point in wasting more time on this topic.

iansjack wrote:I don't think there's much point in wasting more time on this topic.

It's not like anyone actually answered any of my questions or even slightly bothered to help me.
I couldn't care less about libraries if there were someone who would know how to do what I want to do, which is a god damn simple AHCI read/write algorithm.
And just because something doesn't exist it doesn't mean that it can't be easily done.

If you are dissatisfied with the responses to your query you should ask for your money back.

Don't you think blaming others for not explaining concepts to you when you're not willing to do basic research makes you look arrogant and stupid?

As for actual technical reasons why there is no such thing as an AHCI library: AHCI and many other devices rely on kernel-specific support code. For example AHCI requires DMA and interrupt access. For DMA you need a kernel-specific memory allocator that honors the address restrictions that are imposed by each DMA capable device. You need access to PCI configuration registers. The AHCI driver has to plug into the OS' power management. It requires I/O scheduling code.

Sure, you can try to expose all that stuff through a well-defined interface but at that point you already forced consumers of your AHCI library to copy your kernel design. That's why nobody bothers to write an AHCI library for you; you'll have to do it yourself.

If you don't want to (learn how to) write a proper AHCI driver just consider augmenting an existing OS (e.g. Linux) instead. If you actually want to build an OS yourself (and so includes writing drivers) this site and the internet in general provides more than enough resources to get you started (if you stopped complaining and indeed tried to study things).