Getting a handle to a kernel driver (IISR)

Hi!

Due to lesser overhead on IOCTLs i.e. faster calls, I plan to implement a
driver as an IISR. As it doesn't actually need to handle IRQs the ISR is a
dummy. To get a handle to do IOCTLs it seems I have to use
LoadIntChainHandler. As several processes may need to communicate with the
driver, LoadIntChainHandler may be called several times. Does this also
mean the dummy ISR is also hooked multiple times? And if so, is there an
other way to obtain a handle to the driver without hooking the ISR?

Regards
Max

Steve
Tue Apr 11 11:15:18 CDT 2006

I think you need to describe the problem you are trying to solve rather than
the solution you've already decided on. As what you suggest is a really ugly
and bad hack that I don't think solves the problem you've alluded to.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

Max
Tue Apr 11 11:30:09 CDT 2006

Am Tue, 11 Apr 2006 12:15:18 -0400 schrieb Steve Maillet (eMVP):

> I think you need to describe the problem you are trying to solve rather than
> the solution you've already decided on. As what you suggest is a really ugly
> and bad hack that I don't think solves the problem you've alluded to.

First implementations using "normal" drivers where you get a handle via
CreateFile had a run time of about 50us (on a PXA255 at 400MHz) when
calling an IOCTL, even if the IOCTL-handler was an empty function. So these
50us seem to be mere overhead. Using an IISR gave a run time of about
500ns. As 50us are unacceptable I'm searching for a faster solution.

Regards
Max

Richard
Tue Apr 11 12:59:16 CDT 2006

I'm not sure I fully understand your problem, but it sounds like you may be
a little off the rails on the solution.

What is the source of your data? Since you report a latancy, I'm going to
assume it's an interrupt driven process, and that your 50 uSec latancy is
the turn-around for an empty IOCTL from user code (sounds a bit long, but my
experience is MIPS and X86, not PXA-225).

You may be able to use a custom Installable ISR (IISR) and work though
shared memory between the IISR and your user code. That would significantly
reduce the read overhead.

Yous should study the ISR6550 code, which does create a shared circular
buffer to arbitrarily extend the serial port FIFO though software. There is
really nothing that requires you to have a separate device driver loading
the IISR, provided that your application does not need to unload and restart
(IISRs do not like to be multiply loaded).

Debugging IISRs is not much fun. You might slurp printf code out of the boot
loader if you have an available serial port for debug messages, but be
careful, as you cannot link any coredll bits into an IISR.

Good Luck!
--Richard R. Lee eMVP

Steve
Tue Apr 11 14:25:38 CDT 2006

>First implementations using "normal" drivers where you get a handle via
>CreateFile had a run time of about 50us (on a PXA255 at 400MHz) when
>calling an IOCTL, even if the IOCTL-handler was an empty function.

That's not all that unusual for a normal thread on that CPU. The PSL call
layering does have overhead associated with it. Why does the overhead for a
DeviceIoControl call matter. Anytime I've seen cases where someone is
worried about that it's usually due to bad design of the driver. (E.g.
trying to make the driver a simple light weight hardware abstraction layer
that leaves the bulk of the work to the application. )

>Using an IISR gave a run time of about
> 500ns

Here's where you lose me. I have no idea what you are measuring with that
since IISRs can't be "Opened" and are not drivers as they are interrupt
handlers so yes they will get a latency that is extremely short as they are
loaded into locked pages of memory.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

Max
Wed Apr 12 04:28:42 CDT 2006

Am Tue, 11 Apr 2006 15:25:38 -0400 schrieb Steve Maillet (eMVP):

> Here's where you lose me. I have no idea what you are measuring with that
> since IISRs can't be "Opened" and are not drivers as they are interrupt
> handlers so yes they will get a latency that is extremely short as they are
> loaded into locked pages of memory.

But I can do IOCTL calls from user space into the IISR driver. An IISR even
needs to have an entry point for IOCTL.

What I actually need is a central instance to serialize IO on an external
bus. IRQ handling is also an issue, but not the main problem.
The IO-Data isn't comming in like a stream e.g. via RS232 which would make
a shared memory suitable. To give an example: at an arbitrary time an ADC
has to be configured, started, polled for completion and then read. No
interrupts involved here. But so far only IISRs seem to allow fast enough
calls from user space for this purpose.


Regards
Max

Remi
Wed Apr 12 05:34:18 CDT 2006

I am going to be the dirty guy once again...

Why do you focus on puting your code in kernel-deep layers?
Under CE, you can make any kind of low-level access (and even interrupt
handling!) at application level. Actually, the frontier between device
drivers and application code is very narrow and a driver is almost only
another piece of code in another process.
If I were you, I would put my 'special code' into a DLL and figure a simple
scheme involving global events, shared memory or any other IPC technique to
manage multi-process accesses. You will then be sure to achieve the best
possible performances.

Remi

Max
Wed Apr 12 06:43:36 CDT 2006

Am Wed, 12 Apr 2006 12:34:18 +0200 schrieb Remi de Gravelaine:

> Why do you focus on puting your code in kernel-deep layers?
> Under CE, you can make any kind of low-level access (and even interrupt
> handling!) at application level. Actually, the frontier between device
> drivers and application code is very narrow and a driver is almost only
> another piece of code in another process.

Well I know that. But appart from high IO-performance I also need absolute
high priority scheduling. Normal interrupt latency into the user space is
not acceptable. So the big plan is a sort of RT kernel (IISR) that
registers several function pointers directly at OEMInterruptHandler. These
functions are then called from OEMInterruptHandler. To communicate or to
send commands to/from normal user space IOCTLs seem to be suitable.
My problem now is, as described in my original post, how to have multiple
handles to the IISR from several user space processes. Several calls to
LoadIntChainHandler doesn't seem correct.


Regards
Max

Remi
Wed Apr 12 07:48:30 CDT 2006

> Several calls to LoadIntChainHandler doesn't seem correct.

Not really sure of that : for instance, giisr.dll is used by a lot of
drivers concurently without trouble.
The code for SC_LoadIntChainHandler is available in the Private directory
anyway, and it can be traced easily.

The only point I see is that there is a risk of unproductive calls to your
IsrHandler routine from PeRPIsr.

Regards
Remi

Max
Wed Apr 12 09:17:30 CDT 2006

Am Wed, 12 Apr 2006 14:48:30 +0200 schrieb Remi de Gravelaine:

>> Several calls to LoadIntChainHandler doesn't seem correct.
>
> Not really sure of that : for instance, giisr.dll is used by a lot of
> drivers concurently without trouble.
> The code for SC_LoadIntChainHandler is available in the Private directory
> anyway, and it can be traced easily.
>
> The only point I see is that there is a risk of unproductive calls to your
> IsrHandler routine from PeRPIsr.

Thanks. I will have a closer look at the mentioned code.

Regards
Max

Steve
Wed Apr 12 09:21:37 CDT 2006

You are really over complicating the problem or just confusing it with a lot
of non-relevant info. You said no interrupts are involved and therefore
there is no need for an IISR nor a driver. Yes an IISR can be called via
KernelIoControl, which still has a PSL call overhead but doesn't need the
secondary overhead of transitioning into the device manager. However, as
Remi pointed out you can get to your hardware directly from the application
for the absolute best performance (Skipping the KernelIoControl call
overhead too). So you can combine that with an IISR for the parts that
really do need an interrupt. (You don't need a driver to load an IISR. In
windows CE a device driver is just an ordinary DLL with MS defined entry
points that load into the Device manager process space. There's really
nothing you can do in a driver that can't be done in your application
directly if you wanted. The device manager just provides a standardized
method for multiple processes to get access to the driver.)

I'd still say that an application taking a reading from an ADC at a random
point is a bad design for the app/driver. If the app is just randomly taking
readings whenever it feels like it what difference does it matter if it
takes a few more uS to do it? What criteria does the app use to decide when
to take a reading. Shouldn't the device driver be doing that? (This is what
I meant when I said that the typical problem is the driver is too thin a
layer on the hardware.)

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

Max
Wed Apr 12 12:17:16 CDT 2006

Am Wed, 12 Apr 2006 10:21:37 -0400 schrieb Steve Maillet (eMVP):

> directly if you wanted. The device manager just provides a standardized
> method for multiple processes to get access to the driver.)

Well, that's the point.


> I'd still say that an application taking a reading from an ADC at a random
> point is a bad design for the app/driver. If the app is just randomly taking
> readings whenever it feels like it what difference does it matter if it
> takes a few more uS to do it? What criteria does the app use to decide when
> to take a reading. Shouldn't the device driver be doing that? (This is what
> I meant when I said that the typical problem is the driver is too thin a
> layer on the hardware.)

I work for an OEM. It is our customers who write applications accessing the
hardware. As they don't want to bother with the ADC, DAC or whatever
directly, there has to be an abstraction layer. And as I don't know during
writing the driver when they will access the hardware, the access routines
have to be as fast as possible. The past showed that some of our customers
insist on RT and are counting every uS :-).

Additionally I have to use an existing code base for the drivers and the
API if I don't want to reinvent the wheel.


Regards
Max

Steve
Wed Apr 12 13:41:48 CDT 2006

Well you don't get multi-process access management without dealing with a
perf hit for the IPC no matter what mechanism is used. So you have to choose
between maximum performance and greatest generality. Loading your "driver"
as an IISR and using KLibIoControl() is a hack that won't work at all in
secured scenarios as Applications don't get to call KLibIoControl since it's
a protected function. You can create the driver in a more generalized
fashion such that it has built in support for doing timed samples including
bursts, etc... all done inside the driver including triggering an
application provided event at specific points. Creating a stream driver that
does nothing more than take a single sample is just not a good design from a
performance perspective. It's also worth considering whether multiple
applications really need to interact with the ADC simultaneously. (E.g. is
it really sensible to support multiple open handles to the ADC at the same
time?) If not then a static/dynamic library is all you need and that gets
the best performance available.

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com