Re: Device Driver that uploads it's own code?
- From: "Volodymyr M. Shcherbyna" <v_scherbina@xxxxxxxxxxxxxxx>
- Date: Wed, 4 Jun 2008 10:07:40 +0200
Read comments inline,
Suppose the driver needs to handle detection of different bit/byte
sequences and/or timing sequences and in doing so it's expected to
respond/interact with hardware with microsecond precision. But the
detection of these situations, and the details of the exact response,
changes on-the-fly. Because of the high-speed timing response required,
this has to happen right within the driver itself, if I'm not mistaken...
So why would not implement this logic in driver?
though I find it hard to get anyone to commit some actual numbers as to
what actual microseconds it takes to switch between KernalMode and
UserMode?
The general answer is: costly. If I recall correctly Jeffry Richters book
"Advanced Programming", he was saying that on Intel CPUs the transition
usually takes approximatly 1K ticks.
My background being hardware design, which tends to be more real-time and
linear, the idea of fluctuating state and variable latency is sometimes a
bit foreign to me.
Not sure if you have Electronics and/or Process Controller experience but
a common control loop might implement what's called PID (proportional,
integral, differential) where the mathematical calculations to tune the
control loop change dynamically, so that the control loop can be adjusted
manually or even automatically adaptive. Yes, traditionally this is done
in separate external hardware, where the connection to Windows is largely
only for GUI purposes. However, with recent advances in CPU speed and
processing throughput, it's becoming attractive (cost savings potential)
to do this right on the Windows platform, with minimal external hardware.
If my UserMode application could interpret high-level math commads (making
it user friendly) and boil these down to raw assembler code, then upload
to the KernalMode driver for direct execution... it would be a very
flexible system. So if all the code did was make bit shifts,
add/subtracts, logical operations, conditional branches....would it be ok
to upload and run it KernalMode, on-the-fly? It's the same CPU and OP
Codes, right?
Right. Making simple operations like bit shifting, etc is very simple, and
it for sure will work. As for the branches of executions - you probably will
need to take care about address of where to pass execution. It means, you
will need to prepare code in user mode which has relative offsets to code
branches, and in kernel mode after mapping the buffer and before passing
control to code you will need to take care about translating relative
offsets into real addresses in the form:
RealAddress = BaseLoadAddressOfCode + RelativeOffsetToBranch;
To ease security concerns, uploaded code could be scanned/blocked from
making any kernal, i/o, memory calls or interactions outside the context
of the driver and the I/O port it uses. In fact, because the raw code is
generated from a high-level language the the user works from, it simply
won't contain instructions other than directly to the driver's operation
itself.
Looking at it from a bigger picture, I'd essentially like to fake-out or
approach near Real-Time performance for simple applications running on
Windows XP, and completely bypass the need for expensive Real-Time
extensions such as RTX from Ardence, or InTime from Tenasys. The terms
Soft Real-Time versus Hard Real-Time come to mind in this case.
OK, but I ask my question again: why dont you want to do all logics in km
driver?
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights
.
- References:
- Device Driver that uploads it's own code?
- From: respect privacy
- Re: Device Driver that uploads it's own code?
- From: Volodymyr M. Shcherbyna
- Re: Device Driver that uploads it's own code?
- From: Volodymyr M. Shcherbyna
- Re: Device Driver that uploads it's own code?
- From: respect privacy
- Device Driver that uploads it's own code?
- Prev by Date: Re: Get Handle Owner,...
- Next by Date: Re: Get Handle Owner,...
- Previous by thread: Re: Device Driver that uploads it's own code?
- Next by thread: Re: Device Driver that uploads it's own code?
- Index(es):
Relevant Pages
|