How exactly are device drivers and interrupt handlers connected?

[chrstrbrts]

Hi guys,

So, recently, I finished reading Intel's big manual; I learned a ton.

Anyway, I was very disappointed to see that there wasn't any attention paid specifically to two big low level sub-systems for modern computer systems: device drivers and the graphics system.

Despite the fact that the word 'driver' appears 44 times in the PDF (I control-Fed it) there isn't a chapter dedicated to drivers nor any real explanation as to how drivers and interrupt handlers are supposed to interact.

I assume that the interrupt handler at some point calls out to the driver to query the hardware I/O device by reading status registers on that I/O device to ascertain the nature of the interrupt and obtain other status information.

But, where is the device driver stored?

Is it subject to paging, or is it part of the kernel?

I assume that the driver has to occupy the same place in memory every boot, otherwise the interrupt handler wont' be able to find it boot to boot.

What happens if no driver exists for the I/O device?

At initialization, before boot, the UEFI / BIOS should assign the I/O device an interrupt number (by writing to a memory location on the I/O device I think) to call into the IDT.

I don't think that the presence or absence of a driver effects that process; I don't think that the initialization code has any knowledge of drivers at all (wait, what about low level I/O devices like mice that run before the OS is booted? Maybe, I'm not entirely correct here).

If no driver has been loaded for some I/O device and that device fires an interrupt on the line assigned to it by the BIOS, what happens?

Thanks.

 

[chrstrbrts]

Any thoughts, guys?

 

[DaveSimmons]

Device drivers are artifacts of an operating system, so will vary by OS and how it was designed. A driver is just a set of code that the OS has decided to run in response to the interrupts.

Do you want to learn about drivers for a specific operating system like Windows or Linux?

 

[exdeath]

Device occupies memory addresses and IO ports. It has a protocol for sending it commands, checking status, etc at those addresses. It supports hardware interrupts to achieve concurrency by allowing the CPU to move on and not babysit (eg polling in a loop).

Host OS knows nothing about the device as it's proprietary and there isn't a standard for all devices at the hardware level.

OS instead implements a API. Eg DrawRectangle().

Driver is merely vendor provided software that exposes an interface to the API (eg it implements DrawRectangle).

Device software at init time can register an interrupt handler through the OS as well and the OS installs it and adds it to the IDT.

The driver software module is in essence an expansion stub of the OS to bridge the gap between a general purpose API and vendor specific implementation. The software runs in kernel privilege and is basically part of the OS.

When user apps call DrawRectangle they invoke a syscall. OS does what it needs and passes the call up the chain to the driver where your actual commands are built in packets and IO requests (IORPs) submitted to the OS (eg part of HAL) to R/W IO and memory addresses reserved by the device.

If interrupts are involved the IDT simply points to a section of code in the OS memory space owned by the driver module in the kernel non paged memory space so that the driver int handler is invoked to query the hardware for what caused the interrupt, clear the condition, and queue a DPC to process what needs to be processed at a non real time priority.

Back to basics and old school, when a BIOS finds a VGA option ROM after scanning all ISA ranges for the option ROM signature (55AA or something) it calls a defined entry point in that ROM block to init itself. This sets up the int 10 IVT entry to point to the video ROM, among other things, and is effectively installing itself as a driver. When you want mode 13h you just call int 10 asking for mode 13h, you don't have to know the details of which addresses and registers to program with what values to actually program the VGA itself.

Maybe you do that's great, but VGA was the last common ancestor of video cards so now what? Back to needing a driver.

 

[DaveSimmons]

> (wait, what about low level I/O devices like mice that run before the OS is booted? Maybe, I'm not entirely correct here).

A BIOS is a mini OS, with its own disk, keyboard and mouse device drivers.

An older BIOS has no mouse support, and a really old one has no USB keyboard support just PS/2 port keyboards.

 

[chrstrbrts]

When you want mode 13h you just call int 10 asking for mode 13h

How is this done?

I assume you put 13H in a CPU register?

Which one? AX?

Thanks for you replies, guys.

Also, how do vendors actually deliver drivers to customers?

Are the drivers permanently burned on ROM chips on the peripherals themselves and then pulled into the kernel by the BIOS / UEFI every boot?

Are they delivered on a DVD and manually installed once by the customer and permanently added to the kernel that way?

Are they downloaded from the internet?

Generally speaking, if I buy a PCIe peripheral like a GPU or sound card, how will I obtain the driver software for it?

 

[chrstrbrts]

Any help?

 

[Ken g6]

Quoth Wikipedia:

In x86 assembly language the mode is entered when AL is 13h, AH is 0 and BIOS INT 10h is executed.[1]

They mention difficulties accessing this mode from 32-bit or higher.

 

[chrstrbrts]

Quoth Wikipedia:

They mention difficulties accessing this mode from 32-bit or higher.

Thanks.

 

[Apathetic]

AX! You youngin's and your fancy 16 big registers

If I remember correctly (it's been over 20 years since I dealt with this stuff), it went something like this:

mov ah, 0x0 ; zero means "we want to execute the set video mode function"
mov al, 0x13 ; we want mode 13h (this is your "parameter" to "set video mode")
int 0x10 ; make the change

So instead of calling functions by name, you called them by number.

So INT 10 deals with VGA video, INT 13 deals with disk IO, INT 16 was keyboard. There were a bunch of them, but this is all I remember... Sigh...

These sites have some good details for you if you're interested:
http://www.ablmcc.edu.hk/~scy/CIT/8086_bios_and_dos_interrupts.htm
https://en.wikipedia.org/wiki/BIOS_interrupt_call

Dave

How is this done?

I assume you put 13H in a CPU register?

Which one? AX?

Thanks for you replies, guys.

Also, how do vendors actually deliver drivers to customers?

Are the drivers permanently burned on ROM chips on the peripherals themselves and then pulled into the kernel by the BIOS / UEFI every boot?

Are they delivered on a DVD and manually installed once by the customer and permanently added to the kernel that way?

Are they downloaded from the internet?

Generally speaking, if I buy a PCIe peripheral like a GPU or sound card, how will I obtain the driver software for it?

 

[you2]

If i'm not mistaken the original concept of interrupt was tied directly to pins on the cpu (hardware interrupt). When certain events occurred (typing a key) the pia routed the value to some pins and then raised the 'interrupt' pin which triggered the cpu to stop what it was doing; save the current pc (program counter register); and jump to a specific location in memory. You could simulate an interrupt via the INT instruction (mentioned above). Things are a lot more complicated these days but then again we have more sophisticated hardware. The old days were fun because we could build our computers on bread-boards; spend Christmas holiday wiring them and then 40 hours straight debugging them with scopes.