Interrupt philosophy
Posted: Sat Apr 23, 2011 6:20 am
Hi. My OS' code is intended to be strongly typed and fully object oriented, even if in C and even for low-level stuff.
First of all, to better understand the point of view i'm going to propose, i would invite you to have a look at the following blog post
Not all properties are created equal, talking about Plato's "Existential vs Accidental Properties" applied to software.
For interrupt handling, I came out with two possible solutions, with different implications.
In the first one, they exist two entities the "Interrupt" and the "InterruptHandler". Modeling this scenario in C (simpler to post then UML) it is:
The above let it possible to invoke an InterruptHandler on an Interrupt it is not able to handle or, oppositely, handle several interrupts with the same handler.
This implies that an user wishing to register his/her own InterruptHandler has to test the Interrupt's id, both to avoid handling unknown interrupts and switching on different interrupts.
A second design, instead, does not define an explicit "Interrupt" entity but leave it implied in the "InterruptHandler" by making the "interrupt id" an existential property for the "InterruptHandler". This implies that the handler has not to test the interrupt id but it is impossible to write an InterruptHandler able to handle several interrupts.
What do you guys think about that?
First of all, to better understand the point of view i'm going to propose, i would invite you to have a look at the following blog post
Not all properties are created equal, talking about Plato's "Existential vs Accidental Properties" applied to software.
For interrupt handling, I came out with two possible solutions, with different implications.
In the first one, they exist two entities the "Interrupt" and the "InterruptHandler". Modeling this scenario in C (simpler to post then UML) it is:
Code: Select all
/**
* The id is an "existential property" of an Interrupt.
*/
struct Interrupt {
uint32 id;
}
/**
* The interrupt that an interrupt handler is design to handle is, instead, an
* "accidental property" for the handler.
*/
struct InterruptHandler {
void (*handle) (struct InterruptHandler* this, struct Interrupt* interrupt);
}
This implies that an user wishing to register his/her own InterruptHandler has to test the Interrupt's id, both to avoid handling unknown interrupts and switching on different interrupts.
Code: Select all
/**
* This handler is able to handle just one interrupt.
*/
void simpleHandler_handle(struct InterruptHandler* this, struct Interrupt* interrupt) {
if ( interrupt != NULL ) {
if ( interrupt->id == HANDLING_INTERRUPT ) {
// TODO: Handle interrupt
} else {
// TODO: Unknown interrupt
}
} else {
// TODO: Panic
}
}
/**
* This one, insted, is designed to handle several interrupts.
*/
void complexHandler_handle( struct InterruptHandler* this, struct Interrupt* interrupt ) {
if ( interrupt != NULL ) {
swtich( interrupt->id ) {
// Handle several interrupts
}
} else {
// TODO: Panic
}
}
Code: Select all
struct InterruptHandler {
uint32 (*getId)();
void (*handle)(struct InterruptHandler* this);
};
uint32 myHandler_id() {
return HANDLING_INTERRUPT;
}
void myHandler_handle( struct InterruptHandler* this ) {
/**
* TODO: Just handle the interrupt, because this handler
* is guaranteed to be invoked on the right interrupt.
* Nevertheless there is no way to handle several interrupts.
*/
}
) where a class has an empty constructor and thousands of setter method. This kind of code, as you know, is hardly maintainable and hardly difficult to understand by someone new to the project. As a rule of thumb an existential property is one you wouldn't forget in your constructors and without setters, so read-only, since modify them will mean modify the modeled entity. An accidental property is, instead, generally left out constructors and editable by setters.