Re: Device Driver that uploads it's own code?
- From: "respect privacy" <respect__privacy@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 04 Jun 2008 14:54:26 GMT
Integer math is fine.
What people seem to be missing here, is that I'm shooting for a universal driver, where the actual driver code logic is programmed in at runtime and on-the-fly. Nobody can know, prior to runtime, what the driver needs to do, so the flexible way is to make it programmable... by some high-level language preferably on the user side, which interprets the needed functionality into executable raw code and then uploads that raw code to the driver.
If it were just the math calculations, I would make them as variables, then communicate the variables via ioctrl, but it's far more flexibility and control over what the drive does is what I'm after. It's maybe too radical of a concept? It's maybe a threat to established Driver experts, because it would put the Device Driver functionality, directly within the hands of users, so that Device Driver experts are no longer needed :-P
~RP
<daniel@xxxxxxxxxxxxxxxx> wrote in message news:OMIRyajxIHA.4848@xxxxxxxxxxxxxxxxxxxxxxx
So if I understand correctly you want to do proportional, integrals and differentials from a driver in which you are going to operate on standard registers implementing your own floating point algorithms and logic without using FPU or SSE instructions ?.
//Daniel
"respect privacy" <respect__privacy@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:Fgi1k.3758$C12.3205@xxxxxxxxxxxxThanks 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@xxxxxxxxxxxxxxxxxxxxxxxAnyway, 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.
- Follow-Ups:
- Re: Device Driver that uploads it's own code?
- From: daniel
- Re: Device Driver that uploads it's own code?
- From: David Craig
- Re: Device Driver that uploads it's own code?
- 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: Application files;
- Next by Date: Re: Application files;
- 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
|