Shared IRQ's

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply

Do you support shared IRQ's?

Yes
9
60%
No
6
40%
 
Total votes: 15

User avatar
~
Member
Member
Posts: 1228
Joined: Tue Mar 06, 2007 11:17 am
Libera.chat IRC: ArcheFire

Shared IRQ's

Post by ~ »

Do you support shared IRQs in your kernel, or in other words, an IRQ handler that is called by several peripherals and is capable of telling where it has been called from? Or if it doesn't work like that for you, how do you support them, if so?
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

The osdev tutorial over at osdever.net sets this up. It makes it really easy to setup new IRQ's because you just call irq_install_handler... It also means that debugging IRQ's is much easier.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

Can I answer "maybe"?

My kernel implements IRQ waiting with a semaphore-per-IRQ.

To wait for an IRQ, you wait on the semaphore. When that returns (without error) you've got an interrupt, and you're supposed to handle it, and then acknowledge it (to PIC).

Now, this is a normal semaphore, with full thread-queue and everything... so in pseudo driver code:

Code: Select all

   while(irq_semaphore_wait(my_irq)) {
      if(my_device_interrupted()) break;
      // wasn't ours
      irq_semaphore_post(); // increase it back to 1
   }

   // got interrupt 
   handle_device();
   ack_irq(my_irq);
So, since the wait queues are FIFO, if you post()+wait() you get to the end of the list. Ofcourse if you're the only one, or everyone does this, it's an endless loop, but as long as someone takes the interrupt, it's ok.

So as a side-effect of how I've implemented the interrupts, I can relatively trivially support sharing... in theory, and if every driver sharing the interrupt actually supports that.

There's no formal support yet, so it's wouldn't be reliable in any way to do it... but ... it MIGHT work.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Shared IRQ's

Post by Brendan »

Hi,
~ wrote:Do you support shared IRQs in your kernel, or in other words, an IRQ handler that is called by several peripherals and is capable of telling where it has been called from? Or if it doesn't work like that for you, how do you support them, if so?
An IRQ handler should never need to care where it has been called from...

Any OS that supports PCI hardware needs to support shared IRQs. Given that almost all hardware is PCI now it seems very unlikely that anyone would write an OS that won't eventually support shared IRQs.

Of course someone might be writing an OS for ancient machines (80386 and older), future machines (something that uses MSI or Message Signalled Interrupts only, and won't work on almost all current computers), or a different architecture(?).


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Post Reply