Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hal: masking APIs for individual IRQs #30

Open
hawkw opened this issue Dec 13, 2019 · 3 comments
Open

hal: masking APIs for individual IRQs #30

hawkw opened this issue Dec 13, 2019 · 3 comments
Labels
area/hal Related to the hardware abstraction layer

Comments

@hawkw
Copy link
Owner

hawkw commented Dec 13, 2019

this will probably help with IOAPIC (#28) and PIC drivers.

probably something like the existing Control::enable_irq/disable_irq, but for a specific vector

/// Disable interrupts.
unsafe fn disable_irq(&mut self);
/// Enable interrupts.
unsafe fn enable_irq(&mut self);

we can then use this to implement a drop guard API, like enter_critical:

fn enter_critical(&mut self) -> CriticalGuard<'_, Self> {
unsafe {
self.disable_irq();
}
CriticalGuard { ctrl: self }
}

(possibly enable_irq and disable_irq should be renamed to enable_all/disable_all or something — that naming incorrectly implies that they enable/disable a specific IRQ...)

@hawkw hawkw added the area/hal Related to the hardware abstraction layer label Dec 13, 2019
@hawkw
Copy link
Owner Author

hawkw commented Dec 13, 2019

we might actually want the actual implementation of this to be in the Vector trait, with a ref to the interrupt controller; depending on the interrupt, the way it is masked might differ, for example, on x86, it could be a CPU interrupt, a PIC interrupt, or an IOAPIC interrupt...

@hawkw
Copy link
Owner Author

hawkw commented Dec 13, 2019

cc @iximeow

@hawkw
Copy link
Owner Author

hawkw commented Jan 1, 2025

did this for ISA IRQs in #490

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/hal Related to the hardware abstraction layer
Projects
None yet
Development

No branches or pull requests

1 participant