We have written a char driver for our proprietary h/w. This driver
handles a
multitude of interrupts from the h/w in the following fashion: The ISR
reads/saves the status register (indication of which int was hit) in
global, and the marks the BH to run. The BH uses the global to call one
of 32 "ISRs" (an array of func ptrs). I would like to be able to
install an "ISR" dynamically from user code (the module has already been
installed). Is this possible?
If it is possible, how does the build/link work?
thanks,
[email protected]
I'm new at this myself, but how about creating a minor number for each
ISR? When the BH runs, it wakes up the processing waiting on the
device for that ISR. The user code opens as whatever devices it's
interested in and waits for interrupts using select.
robert
* Brett Smith ([email protected]) [001030 09:25]:
>
> We have written a char driver for our proprietary h/w. This driver
> handles a
> multitude of interrupts from the h/w in the following fashion: The ISR
> reads/saves the status register (indication of which int was hit) in
> global, and the marks the BH to run. The BH uses the global to call one
> of 32 "ISRs" (an array of func ptrs). I would like to be able to
> install an "ISR" dynamically from user code (the module has already been
> installed). Is this possible?
>
> If it is possible, how does the build/link work?
>
> thanks,
> [email protected]
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
On Mon, Oct 30, 2000 at 11:06:59AM -0800, [email protected] wrote:
> I'm new at this myself, but how about creating a minor number for each
> ISR? When the BH runs, it wakes up the processing waiting on the
> device for that ISR.
... which won't get run until after the interrupt is processed, but
the interrupt won't get processed until it's run. Nope.
Tim.
*/
At 17:23 30/10/2000, Brett Smith wrote:
>We have written a char driver for our proprietary h/w. This driver
>handles a multitude of interrupts from the h/w in the following
>fashion: The ISR reads/saves the status register (indication of which int
>was hit) in
>global, and the marks the BH to run. The BH uses the global to call one
>of 32 "ISRs" (an array of func ptrs). I would like to be able to
>install an "ISR" dynamically from user code (the module has already been
>installed). Is this possible?
>
>If it is possible, how does the build/link work?
Of course it is possible. - There are drivers out there doing similar
things. - Unfortunately while the one I actually know is open source the
program attaching to this driver is not open source so you can only see the
kernel side of the solution. )-:
Download: ftp://ftp.sigmadesigns.com/NetStr_2000/NetStream2000-0.1.033.0.tar.gz
Gunzip/Untar the archive and look in the Barbados/kernelmode directory in
the file quasar.c. - In that file you will find the implementation of some
IOCTLs and the one you will find most interesting is IOCTL_SEND_PID which
is used for the purpose of registering a user space ISR with the kernel
mode driver.
This concept can easily be extended by another passed in argument
containing which ISR to register with this call or you could do them all at
once whatever suits you.
Hope this helps.
Regards,
Anton
>thanks,
>[email protected]
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>Please read the FAQ at http://www.tux.org/lkml/
--
"Education is what remains after one has forgotten everything he
learned in school." - Albert Einstein
--
Anton Altaparmakov Voice: +44-(0)1223-333541(lab) / +44-(0)7712-632205(mobile)
Christ's College eMail: [email protected] / [email protected]
Cambridge CB2 3BU ICQ: 8561279
United Kingdom WWW: http://www-stu.christs.cam.ac.uk/~aia21/
On Mon, 30 Oct 2000, Tim Waugh wrote:
> On Mon, Oct 30, 2000 at 11:06:59AM -0800, [email protected] wrote:
>
> > I'm new at this myself, but how about creating a minor number for each
> > ISR? When the BH runs, it wakes up the processing waiting on the
> > device for that ISR.
>
> ... which won't get run until after the interrupt is processed, but
> the interrupt won't get processed until it's run. Nope.
>
> Tim.
> */
>
An interrupt will occur at any time. The user-pages may not be in
memory at that time.
I suggest you do your ISR in the driver (or module) where it really
should be done. The ISR pages are always present.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.