OSDev.org

I don't know a great deal on the subject, but i think i understand where people are coming from and thought id throw in my 2 pence.

UDI, and i presume many peoples opinion on what a driver is, mixes how to access the hardware with how the hardware functions/is used.

I would love uniform access to hardware, something i believe is possible. But uniform function is not practical. The more complex the hardware gets, the more interacting components there are, and each component requires "function" to operate. How you use hardware is best kept flexible.

As for uniform access, A good wiki or standard library is just as good as anything.

UDI, and i presume many peoples opinion on what a driver is, mixes how to access the hardware with how the hardware functions/is used.

What a driver does is converting from a generic interface (be it either r+w+ioctl or specific to the device class) to hardware accesses. UDI is different from the typical driver because it does not execute the hardware accesses directly but rather passes them on to a hardware controller outside the driver.

Combuster wrote:

UDI, and i presume many peoples opinion on what a driver is, mixes how to access the hardware with how the hardware functions/is used.

What a driver does is converting from a generic interface (be it either r+w+ioctl or specific to the device class) to hardware accesses. UDI is different from the typical driver because it does not execute the hardware accesses directly but rather passes them on to a hardware controller outside the driver.

So no driver contains policies?

Define "policies". They exist at so many levels and interpretations that any piece of sourcecode is influenced by at least some.

Combuster wrote:Define "policies". They exist at so many levels and interpretations that any piece of sourcecode is influenced by at least some.

Policies which are logic of some usage of the hardware.

Yes exactly. The more complex the harder it is to "uniform" into one shoe fits all.

I personally see a driver as only access, a representation in code of the direct hardware into some common form. (set_gtd() etc)

I would then have a server that provides the usage of that hardware. But i believe some people have both together as a "driver"

I personally see a driver as only access, a representation in code of the direct hardware into some common form. (set_gtd() etc)

That is not a driver, that's an abstraction that gives a name to magic numbers. The resulting interface is still 100% device dependent and cannot be used by any generic application or multiplexer. In essence, only your servers are worthy of the term "driver"

UDI drivers are actual drivers like the rest of the world defines that term. They actually turn a device-specific interface into something more device-agnostic.

Ah right, my apologies.