"The Prisoner" <nospam@[EMAIL PROTECTED]
> wrote in message
news:fvvusc$ts9$1@[EMAIL PROTECTED]
> Jens Thoms Toerring wrote:
>> The Prisoner <nospam@[EMAIL PROTECTED]
> wrote:
>>
>>>I was reading about interrupts, and I got to thinking it would be a
real
>>>neat thing to use interrupts for program-wide exception handling. What
I
>>>haven't been able to find is a clear guide or example program for how
to
>>>install a C function into the IDT.
>>
>>
>> This is completely system dependent (assuming a system has an
>> "IDT" at all and the operating system lets you get at something
>> that low level which many probably won't, even if you have root
>> or admistrator privileges). And what about a multi-tasking
>> system? Just think about the situation that you would get in
>> if each programs would mess around with the IDT. I guess the
>> only system this could somehow be made to work would be DOS.
>> If that's you're system you probably better ask in a group
>> that specializes on system specific programming under DOS.
>
> Jens,
>
> Are you 100% sure about that? I understood that in Real Mode, the IVT is
> used, while in Protected Mode the IDT is used. So it should be possible
to
> make use of the IDT under Windows or Linux.
>
> What I don't know is how to write a function's address into the IDT...
>
I doubt there is any specific mechanism for this.
more so, this would be a horror.
first off, you would need to have an interface for this in the kernel (a
set
of registerable interrupt handlers).
however, this will only really cover kernel space.
why? do you understand how premptive multitasking works?...
this (along with ring0/ring3 issues), makes a major problem for handling
interrupts in userspace.
in effect, the address space of the running process is regularly swapped
out.
so, a tiny fraction of the time, any such handlers would point into your
app's process, and the rest of the time, they will point to the same
address, in any of any number of possibly running processes.
so, in the kernel, you could handle the interrupt, but then would need
some
way to transfer it to the right process. this would either require
swapping
processes on interrupt, queuing messages for particular processes, ...
none of this is very good...
however, although usually system specific, more than a few interesting
things can be done via the 'signal' mechanism...
>>>And what happens about passing arguments?
>>
>>
>> You can't pass arguments to interrupt handler functions since
>> they don't get called in the traditional sense, there's no-
>> thing that could pass it arguments.
>
> Understood. I think a void function(void) will be OK.
|
