what to do if a driver tries to install over an existing irq

[earlz]

I am attempting to remake my interrupt system and now have it to where I can install interrupts(before it had to be hard-coded)

the problem is what if you try to install an irq hook(or interrupt) when 1 is already installed

should I just return 0 signifying failure
If I support unlimited hooks, it could cause interrupts to freeze up when a driver messes up

so really what other ways are their to do this?

[durand]

If you have multiple drivers sharing the same IRQ, it's sometimes called IRQ sharing. This is kinda common, especially with PCI drivers, so it's something you should support.

When the IRQ occurs, each driver needs to be called in turn and requested to handle the IRQ. The driver can then look at their device and determine if the IRQ was intended for them. If it successfully handles it, then the driver can return a success indication. Otherwise, it can return a not handled indication and the kernel should try the next driver for the IRQ.

And drivers need to be trusted to a certain degree, ultimately. They are messing with the hardware directly.

[Pype.Clicker]

i can see two main options.
Either you want to install your new handler because you want to replace what's going on, or because you want to augment it.

The typical behaviour in DOS was to let the new driver read the former IRQ vector, store it somewhere, and write its own address instead. Then, if you want to augment the functionnality, you just call back the former vector if you detect the IRQ is "not for you". This, of course, only make sense if your hardware lets you "probe" IRQ status of your device without actually altering the state.

Otherwise, the former vector was just kept for uninstallation purposes.