[mil...@krutt.org: Re: Delaying an interrupt handler]
- Forwarded message from Milton Krutt - Date: Tue, 7 Apr 2015 18:46:46 +0200 From: Milton Krutt To: Malte Vesper Subject: Re: Delaying an interrupt handler Not that late! I take your advice, and I inform all the folks who suggested me to jump on a new kernel that now I am on a 3.19! So their hints are still welcome. Bye > Despite beeing fairly late, take a look at threaded interrupt > handlers, they might help you. You will handle the interrupt fast > but you can delay doing the actual work. In the threaded part of the > interrupt handler you can sleep and thus use semaphores. > > hope it is still useful - End forwarded message - ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Delaying an interrupt handler
> On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt wrote:
> > Hi.
> > It is known that no semaphore synchronization should be
> > used inside an interrupt handler.
> >
> > Anyway, I am looking at a freeBSD device driver (written by
> > a profesionist) and there are semaphores inside an interrupt
> > handler's subroutine.
> >
> > Since I should port to linux that driver, I ask you how can I
> > reach such synchronization under linux; I tried to use semaphores
> > inside my handler but I got complains, and I don't want to break
> > the law, so no semaphores for me.
>
> Perhaps spinlocks could be the solution :).
>
> 2.6.10 please no - :), Linux kernel is now at 4.0.
>
> Daniel.
Yes and no. The routine the int. handler's delay depends on has to
make some non atomic work. So if I lock a spinlock and then I do some
"lengthy" (i.e. non atomic) job, then I get a warning message like
"spinlock held while being preempted" (or similar). In symbols, you suggest
something like
process P{
spin_lock(lock);
non_atomic_function();
spin_unlock(lock);
}
int. handler {
spin_lock(lock);
do_things(); /* preferably atomically */
spin_unlock(lock);
}
My first attempt is still to avoid both semaphores and the above remedy,
in order to delay the int. handler up to a desired point.
Thanks!
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Delaying an interrupt handler
On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt wrote: > Hi. > It is known that no semaphore synchronization should be > used inside an interrupt handler. > > Anyway, I am looking at a freeBSD device driver (written by > a profesionist) and there are semaphores inside an interrupt > handler's subroutine. > > Since I should port to linux that driver, I ask you how can I > reach such synchronization under linux; I tried to use semaphores > inside my handler but I got complains, and I don't want to break > the law, so no semaphores for me. Perhaps spinlocks could be the solution :). 2.6.10 please no - :), Linux kernel is now at 4.0. Daniel. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Delaying an interrupt handler
Hi.
It is known that no semaphore synchronization should be
used inside an interrupt handler.
Anyway, I am looking at a freeBSD device driver (written by
a profesionist) and there are semaphores inside an interrupt
handler's subroutine.
Since I should port to linux that driver, I ask you how can I
reach such synchronization under linux; I tried to use semaphores
inside my handler but I got complains, and I don't want to break
the law, so no semaphores for me.
The scenario is the following:
firmware downloader {
while(fw_blocks--){
/* the call below will cause an interrupt */
load_block();
/* sleep unitl the int handler ackn's the previous
operation, and prevent ANY int. handler operations
until the process goes actually to sleep through the
following call */
sleep(); }
}
int handler {
if(the process is NOT asleep)
wait();
wake up the process.
}
NOTE: I am on a 2.6.10 in order to be closely tutored by LDD3.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
