Re: Device Driver that uploads it's own code?
- From: "m" <m@xxx>
- Date: Tue, 3 Jun 2008 19:39:08 -0400
One reason why you are having difficulty quantifying the non-determinism of
Windows latency is that it can vary wildly with different hardware and
software configurations. If you can control the config, then you can
probably compute some probabilistic measure of latency that might be good
enough for your purposes.
But whatever you can come up with, there is no reason to send code to the
driver to implement an adaptive timing loop; using a high-level language to
compile in UM does not guarantee anything about what crap a driver might
receive (crashing the system or worse); and I doubt that any process control
application can be sensitive to the difference between the difference
between a floating point approximation of a timing function and a more
coarsely discretised version that can be implemented with integer
arithmetic.
"respect privacy" <respect__privacy@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:Fgi1k.3758$C12.3205@xxxxxxxxxxxx
Thanks to make this clear !
To provide the "more info" as requested...
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...
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? 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?
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.
People keep circulating opinions like Windows is non-deterministic by
default and should NEVER be used for Real-Time control without a Real-Time
extension (or switch to Windows CE is another option). I'll accept that
wise warning, but what I don't accept is that no where will anyone provide
practical bench-mark tested hard numbers as to how bad the
non-deterministic behavior actually is. Many process control situations
are very tolerate of the odd random delay imperfection in small
millisecond range, if it only happens less than 1% of the time.
Presented with the #1 most popular hardware/software platform, a PC
running Windows XP, it's very unpleasant to always be told by the so
called experts... you can't, you shouldn't, it's not good to, ....when
clearly the CPU has the performance capability to meet the required
duties, without expensive separate Hardware/Software always being
required.
;-) I await the flames....
___
~RP
"Volodymyr M. Shcherbyna" <v_scherbina@xxxxxxxxxxxxxxx> wrote in message
news:ew#nA$ZxIHA.5892@xxxxxxxxxxxxxxxxxxxxxxx
Anyway, if you need dynamically extend functionality of your application,
look into direction of plugin based system. You can have plugins of both
types: user mode and kernel mode. If you design a well interfaces, the
whole system might be powerful in terms of extensibility.
--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Volodymyr M. Shcherbyna" <v_scherbina@xxxxxxxxxxxxxxx> wrote in message
news:eMAeO8ZxIHA.4952@xxxxxxxxxxxxxxxxxxxxxxx
[...]
Is it possible to have only the outer skeleton of a device driver,
where the inner code logic is uploaded at runtime from the users own
application that uses the driver?
Yes. It is possible, but the code you pass from user mode is just unable
to be run in kernel mode without special preprocessings. The problem is
that user mode code usually calls some functions, which are not present
in kernel mode.So you need to pass a simplest code which does not rely
on api, or preprocess the code, so that the offsets to import functions
point to the simular or the same procedure in kernel mode (this task is
complex).
I'd like to give UserMode applications full control/configuration and
runtime alteration of the driver's behavior. For example, if the
driver must deal with complicated timing and sequencing issues on
real-time in/out data streams, and those issues are not know until
runtime or might even change during the application's runtime, how else
can that be coped with? Seem impractical to have a library of 1,000's
of slightly different device drivers and always be unloading reloading
different drivers to accommodate different functionality that changes
on-the-fly. Or to have a mega-driver with millions of different code
branches to account for all possible combinations.
[...]
Well, believe me, kernel mode programming is not an easy thing. Its
better to use decomposition approach: devide task into small sub tasks,
which are solved by appropriate module (driver).
Maybe this is what is meant by UserMode driver? I'm still not clear on
difference between a KernalMode and UserMode driver, and under which
situations I would use either one, and their respective advantages
disadvantages.
It depends on what you are trying to accomplish. Give us more info.
Is there some kind of digital signature that's within all .SYS files,
which is tested for validity before it's allowed to load or run?
If so, is there a "hack" workaround to get past such limitations?
You have to sign binaries in x64 version of Vista and further OS. Why
would you need to hack it?
--
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: Device Driver that uploads it's own code?
- Next by Date: 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
|
