linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Nizette <bn@niasdigital.com>
To: "Douglas, Jim (Jim)" <jdouglas@avaya.com>
Cc: Embedded Linux mailing list <linux-embedded@vger.kernel.org>
Subject: Re: UIO - interrupt performance
Date: Mon, 20 Oct 2008 21:28:21 +1100	[thread overview]
Message-ID: <1224498501.3954.50.camel@moss.renham> (raw)
In-Reply-To: <5958B8D7916AB84781FE0E7B57C218CB75AB98@306900ANEX2.global.avaya.com>


On Mon, 2008-10-20 at 10:55 +0100, Douglas, Jim (Jim) wrote:
> We are contemplating porting a large number of device drivers to Linux.
> The pragmatic solution is to keep them in user mode (using the UIO
> framework) where possible ... they are written in C++ for a start.  
> 
> The obvious disadvantages of user mode device drivers are security /
> isolation.  The main benefit is ease of development.  
> 
> Do you know what the *technical* disadvantages of this approach might
> be? I am most concerned about possible impact on interrupt handling. 
> 
> For example, I assume the context switching overhead is higher, and that
> interrupt latency is more difficult to predict?  

Userspace drivers certainly aren't first class citizens; uio and kernel
mode drivers generally aren't really interchangeable.

The technical disadvantages of userspace drivers are that you don't have
access to kernel subsystems, you can't run any userspace content in irq
context so everything needs to be scheduled before it can be dealt with.
A UIO driver still needs a kernel component to do acknowledge the
interrupt.  As such when you say "interrupt latency" you need to define
the end point.  A UIO driver will have it's in-kernel handler called
just as quickly as any other driver but the userspace app will need to
be scheduled before it receives notification that the IRQ has fired.

The technical advantage of a UIO driver is that devices which only need
to shift data don't have to double-handle it.  e.g. an ADC card doesn't
need to move ADC results from hardware to kernel, kernel to userspace,
it's just one fluid movement.

What kind of device drivers are you talking about?  They have to be of a
fairly specific flavour to fit in to a UIO model.  Linux isn't a
microkernel, userspace drivers are quite restricted in their power.

FWIW there is some (out of tree) kernel code written in C++, it can be
done but you have to avoid the standard c++ library which unfortunately
includes things like 'new'.

	--Ben.

  reply	other threads:[~2008-10-20 10:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-20  9:55 UIO - interrupt performance Douglas, Jim (Jim)
2008-10-20 10:28 ` Ben Nizette [this message]
     [not found]   ` <Pine.LNX.4.58.0810200258210.2562@vlab.hofr.at>
2008-10-20 22:12     ` Ben Nizette
2008-10-21  6:57       ` Wolfgang Grandegger
2008-10-21  9:32         ` Ben Nizette
2008-10-20 10:30 ` Christian SCHWARZ
2008-10-20 11:55 ` Marco Stornelli
2008-10-20 13:20   ` Paul Mundt
2008-10-20 16:13   ` Bill Gatliff
2008-10-21  8:36     ` Marco Stornelli
2008-10-21  9:01       ` Alessio Igor Bogani
2008-10-21  9:30         ` Marco Stornelli
2008-10-21  9:37           ` Ben Nizette
2008-10-21 10:24             ` Marco Stornelli
2008-10-21 10:28             ` Wolfgang Grandegger
2008-10-21 11:39               ` Bill Gatliff
2008-10-20 12:48 ` Thomas Petazzoni
2008-10-20 16:25   ` Bill Gatliff

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=1224498501.3954.50.camel@moss.renham \
    --to=bn@niasdigital.com \
    --cc=jdouglas@avaya.com \
    --cc=linux-embedded@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).