From: milton@krutt.org (Milton Krutt)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Delaying an interrupt handler
Date: Mon, 23 Mar 2015 06:46:23 -0700 [thread overview]
Message-ID: <20150323134622.GA4933@debian> (raw)
In-Reply-To: <CAEnQRZDQrnNjxKtDSqmmA+QFHYJbXoWWE=cHEPVE7LOLHA31Uw@mail.gmail.com>
> On Mon, Mar 23, 2015 at 2:18 PM, Milton Krutt <milton@krutt.org> 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!
prev parent reply other threads:[~2015-03-23 13:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-23 12:18 Delaying an interrupt handler Milton Krutt
2015-03-23 12:46 ` Daniel Baluta
2015-03-23 13:46 ` Milton Krutt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150323134622.GA4933@debian \
--to=milton@krutt.org \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.