Re: [Gumstix-users] Need advice on multithreading in Gumstixbetween ADC via SPI and storing data in CF card

[Ryan R. <rjr...@uc...>]

Ned Forrester wrote:
> Ryan Rapetti wrote:
>   
>> Ned- I'm sure about the PXA series, but typically when an interrupt is 
>> thrown the hardware calls the kernel and passes it the interrupt type 
>> and any other data it might have. You'd have to fix the kernel so that 
>> when the NSSP buffer full interrupt is thrown, it calls the userspace 
>> code. I don't see the point especially since you'll need kernel 
>> permission to handle an interrupt correctly. I've done some interrupt 
>> handling on the mcore, but in that case the hardware calls the correct 
>> interrupt handler directly, since there really isn't a kernel.
>>     
>
> Certainly.  I have been rewriting a kernel driver, so I know how
> interrupts are handled inside the kernel.  I am just not sure if there
> is an existing method, or if someone has already hacked a small driver,
> to allow a user-space routine to field and interrupt.  I doubt it, for
> the reasons you point out.  There seem to be various user space methods
> out there, like the whole direct register capability that uses /dev/mem
> and mmap() to make the device registers appear in user space; normally
> this would be big security risk, but who cares on a Gumstix.
>
>   
It's an interesting idea. I don't see why it wouldn't be possible, you'd 
just have to play with the saved stack state so that when the driver 
returned it would dump into the userspace code. Seems like the kernel 
wouldn't like that though, since it would screw up the scheduling of 
whatever was interrupted. You'd have to have the userspace code throw a 
software interrupt to jump back into the kernel, restore the state that 
the first interrupt wiped, and jump back into that. But if the userspace 
handler itself got interrupted, you'd be screwed. You'd have to have a 
very, very good reason to want to handle the interrupt in userspace. 
Hmm, anybody out there use Mach? Microkernels handle a lot of kernel 
services in usespace, but I'm not sure where this sort of thing would 
fall. The easiest way to allow user access to the interrupt handling 
would be to have it call a function from within the handler and let the 
user implement the function. Again, a scary security risk on anything 
but a gumstix.

Ryan