OSDev.org

As far as I understand the driver development is the problematic part. Isn't there any universal way of querying the driver from Applications ? I know there's UDI, EDI. I looked at all that intel documentary for their graphics chip, it's so stupid and complicated. I think it should be something like this:
1. I set the card to a mode
2. I pass buffer of data containing some graphical information 2D,3D
3. I get some output back
Basically a universal way of querying hardware. So my question is about universalizing the writing of drivers. How is that thing programmed, I have no idea, it's so complicated ?
Also, as far as I can see what the driver can do depends on the hardware (the graphics chip), so how do I create a universal interface that could be utilized from applications so it remains the same even if I change my hardware ? How do I detect hardware in first place ? I want to be able to detect anything I have and then simply load the necessary driver. Any ideas about how those drivers communicate with hardware ? I couldn't understand anything from Intel's documentation. No overview no nothing. It's insane. I taught it would be stanrdardized so I implement a standard and the driver can utilize all hardware that support the standard. Is every graphics card really different ?

1. There is no universal way of querying hardware; there are so many types and so bany different ways of querying them. For example, a graphics card and network card will most likely be on the PCI(e) bus. The PCIe bus itself will be found with ACPI. A battery/adapter will be found with ACPI's AML.
2. Few hardware is compatible. Each graphics card has a different way of setting modes. 2D and 3D acceleration is not easy either, and each card has a different way of achieving them.
3. When you create a standard driver interface, it doesn't matter as long as the device-dependant code is transparent to the user.
4. Drivers communicate with hardware normally by two ways: PMIO and MMIO. PMIO (port-mapped I/O) is done using the x86's IO bus. MMIO (memory-mapped I/O) is done using the memory.

There is a standard interface for graphics though; VESA lets you use high-resolution graphics but without acceleration. But that is BIOS, and not a "real" driver.

Graphics hardware is complicated, and it has been getting progressively worse over time. Trying to tackle a modern device first thing around is probably not the best thing to do. Instead, they all understand VGA so you have one native driver to deal with the basics. In addition you have the option to use the firmware to set a mode at boot and live with it. The latter will get you higher resolutions, but doesn't actually teach you any but the most trivial hardware details.

If you can get your hands on an ancient (486-pentium-1-2) era machine, you'll probably get a video card that's much easier to tinker with than a modern intel.


Note that there's two sides to the story, you have a driver that translates a generic interface into device specifics, and you have everything that actually decides what to draw using that interface. It can be a challenge of its own to keep those nicely separated in the first place.

You can design an OS where "universal way" can be implemented.

But usually applications just call an API of a library without any purpose to call specifically a driver. The library can be implemented by OS developers or it can be an independent product. Independent product can be included in the OS distribution as it's part or it can be delivered in another way.

It means from the point of view of an application developer drivers are hidden under an abstraction layer like virtual file system or graphics rendering language. Exposing a driver directly to the application developers is often not a good idea because application developers want to have a solution ready to use instead of some bothering low level details. But sometime the driver level can help the application developer to get better performance in case the OS developers were too lazy to expose a consistent API with enough low level details, usually they describe such decision as "security driven", but in fact it's just the lack of efforts to implement a good and consistent design (time and resources constraints or dumb laziness).

It's bad idea to create such very specialized hardware. For the graphical information to be finally presented to a user there should be some processing in between. The processing means there should be an algorithm. The graphics related set of algorithms is very large and just can not be implemented in hardware (still not enough transistors). Also, if some algorithms will be implemented at the hardware level then it narrows too much the area where such hardware can be useful and as a consequence there will be a very small market for such hardware. Hardware with very small market is usually a loss making investment.

That's why there are universal chips that can use different algorithms. But algorithm requires a developer to implement it. And developer wants enough low level ways to control the hardware. Such ways are usually look like a plain old assembly language with an instruction set corresponding to the particular hardware. So, there are assembly languages for every graphics card. Instruction sets from different vendors can differ a lot, but for a one product line of one vendor there can be too little differences. In fact the complexity of the graphics drivers is just a reflection of the differences among the hardware of many vendors. Also there is the legacy problem, when a vendor sees it's too costly to invent a new instruction set every time and to teach the developers, who implement software for the vendor's hardware. So, the legacy and the lack of standards make the world too complicated. Would there be a unifying standard we now could develop graphics drivers just like we develop the x86 code.

The unifying standard should go first. Next you can write a universal driver. Or you can write an OS that hides the complexity from application developers under the well designed layer of abstraction (usually it's called architecture).

Drivers represent a solution to a typical chicken-egg problem -- How can you write an application for hardware that doesn't yet exist?

Using drivers allows both the hardware and the software designers to agree on a common interface point, so that they can both design their systems independently, but be relatively certain that they will work together when they are done.

In the early days, applications had to be written to work with specific hardware, and new hardware had to maintain compatibility with old hardware, so that old applications didn't need to be completely rewritten every time a new piece of hardware was released.

So, drivers allow virtually any software to work with any hardware. But the problem is that now both the software and the hardware can only implement functionality that has been defined by the driver. This is why there are 12 versions of DirectX. Each new version adds a handful of new features, and the hardware and the software have to be redesigned to support each new DirectX version.

So this is the problem with creating one driver... only the features in that driver will be supported, and no new features can be added without completely redesigning both the applications and the hardware. But, it's still the best solution that anyone has come up with, so far. If you can figure out a way to solve this issue, you could probably get a great paying job at Intel, AMD, or ATI. Let us know what you come up with.

In other words, one can never design a driver architecture that can cover every future development in a particular kind of hardware.

Ehehe. I just wanted to make sure we really deal with different format of data and different way of querying hardware, because the hardware varies greatly as omarrx024 suggested.
Embryo2 thanks, I am also new on this site . But you yourself came to the conslusion that I came to. ANd that is that we'll have to start writing drivers the same way managed code works. This means you'll simply program it once the same way you write your x86 code using a different language. On the running OS there will be simply unpacking and repacking of the data format and changing the code that refers to this data. That's all. As far as I know graphics theory is taught the same way no matter what university it is. SpyderTL made me raelly laugh, becasue I think Intel are really retards, it will be interesting if I come with this driver writing language and architecture that will allow us to write it once and not care about the applications above the driver stack and the hardware below. It really excited me, in an almost sexy way. And folks like onlyonemac really motivate me becasue they say it's impossible and that's all , topic closed . When in fact I am totally on the opposite opinion. There will be mapping, similar to what you have when you use data entities and have the code querying different data management systems. Thanks for making that PMIO and MMIO clarification. So I need more documentation about how hardware is organized and how they create all those different functional units that actaully employ the same algorythms, becasue that's the key the algorythms That's what we want to utilize , the data can be in any format you really don't care in what way they are being put in memory as long as the code gets the right address. Write once ! run everyhwere ! driver architecture. I have another question. Does that PMIO means that a port is as much as a single number lets say 32 bit or 64 bit, and the only issue is really the MMIO, becasue the hardware actually pulls the data himself from memory ? When you have PMIO you still have to move data from memory (RAM) to ports, how is that done ? I need more docs if anybody can help to have an insight about how that works, to see it explained in a simple way. As to wheter I will get in Intel or not , that's not important they care not about what poeple really do . It's trivial really to solve that issue. I'll be glad if I have time and docs do analyze it and come with my own idea about how it must work. There must be different classes of devises, all graphic cards do the same, as all keyboards in general.

Learning to load Win9x, DOS, Linux and Windows NT drivers is gold.

At least it will allow us to configure the devices to enable and stay using them, and access their standard capabilities.

It's done easy because now we can use the functions that are packed inside standard driver functions with the same names. Think about the function names that a video driver would have (switch mode, get list of modes, get current mode resolution metrics), and the names that a sound driver would have, despite the actual "black box" hardware programming details.

We can now use their driver CDs or driver code.

Hardware development is maybe the funniest and most entertaining part of Operating System Development, but only if you deal with standard hardware you know how to access. Trying to program the rest of the hardware and cover it all, even just all your machines and peripherals on your own is't possible in a reasonable time.

That's why I say that being able to use existing drivers, no matter if they are DOS COM files that just run and leave behind a configured peripheral. It doesn't matter if they are Win9x VxD or Windows NT/XP SYS files, or if the are Linux drivers in ELF or AOUT format. We will need to learn how to use the loading aand calling mechanism for those sort of drivers, because we will certainly need them in our OS for it to run in a practical way in real-world hardware.

There's really no option but learning to load drivers from other OSes and standardize from there. So learning that very detail is gold. It's also much easier than learning to program all necessary nonstandard hardware.

Thanks for informing us about this new religion

If it's so easy, maybe just go ahead an try to implement it, and when you come back, we'll talk about it.

I thought about this too, but I need some documentation about detecting what hardware I have and how to program a basic driver for a sound or graphic card. Any documentation and books are welcome. BTW all that music and video stuff on the Internet is making me stupid, I better give up from it completely, it makes people like monkeys, all that youtube. This already will improve my speed to develop whatever. I noticed it spoils people's brains and nature. I better write drivers for it than getting smashed by it. I need documentation and books of how I can get some code working and in what way it looks when querying hardware, also how I can discover what hardware is present. I know there must be some socket standardization and standards for discovering installed hardware.

For x86 it's mostly ACPI, PCI and USB that you need to read about. OSDev wiki has corresponding introductory articles.

Enumerating the PCI devices in a system isn't hard.

For sound, basically everything is hdaudio today, which is well documented. Except, I guess, if it's USB audio, which should be well documented as well. Both are relatively complex things, though, so if you never wrote a hardware driver, I wouldn't suggest that you start with these. Network and storage are usually a bit simpler, especially when you start with the older devices.

As for graphics, the only generic thing that exists is VBE. Otherwise, you get to implement drivers for every single device. Some of them are documented at least partially (and I hear the documentation is insanely hard to understand if you're not very familiar with graphics hardware already), others don't have any public documentation at all. So in practice, VBE it is for your hobby OS.

I need some books or documentations and examples of how that is programmed for intel for instance . I know intel has lots of documentation. I pretty much got the idea about those things, nothing new. There's a PCI bus that corresponds to I/O space and there's Host Bus Adapters that connect other buses (SCSI, etc.) to the PCI. Sockets are on the buses. There's also bridges that connect one bus type to another. And an interrupt controller. I need to know how to deal with that I/O to memory mapping and how to enumerate too, how is it simple, where is it documented. I need some basic tutorial and examples of how to interface with hardware.

Have you actually read PCI or VGA Hardware and VGA Resources?