Thanks Tim…
“It can mean either thing.? When I think of “device emulation”, I think
about writing a driver for a piece of hardware that doesn’t exist.? So,
applications would use my driver as if the hardware were present, when
it was not actually there.”
It means that to an app , it should look like its actually interacting with the hardware, which in turn? implies that a device emulation driver has to implement most of the interface level functionalities while actual hardware level tasks can be delegated to lower level actual driver.
So if my emulated serial port driver, provides xmit and receive queues, follows UART standard , maintains timer for coordination between xmit and receive queue and then call the lower level driver to place the char on to the CMOS buffer,? is correct.
So should I understand that an emulated driver needs to implement most of the functionalities of the lower level driver (interface functions) and, as pointed by Tim, can be used to add new features but will delegate the lower level tasks of interacting with hardware to the lower level driver.
?
Thanks
Anshul Makkar
www.justkernel.com
From: Tim Roberts
To: Windows System Software Devs Interest List
Sent: Thursday, 19 January 2012 11:18 PM
Subject: Re: [ntdev] Device Emulation Driver
anshul makkar wrote:
>?
> I am just trying to understand the device emulation driver and device
> emulation technology as a whole. What i have picked is a serial port
> driver (the simplest one). Device emulation driver is required by me
> for one of virtualization project.
>
> In the source code, what I have found is that the serial port
> emulation driver implements timer functionality, maintain xmit and
> receive queues, and calls the callback function for lower level serial
> port driver that modifies the CMOS registers…
>
> Now what I used to think is that emulation driver are just a kind of
> filter driver that doesn’t perform any task on their own but pass the
> buffers to the lower driver. But in this case my emulated serial port
> driver is implementing most of the functionalities of the actual
> hardware driver (mainlining timers, working according to UART specs,
> maintain its own receive and xmit queues) .?
>
> Is this what the emulation software is meant to be i.e implement the
> complete functionality of the underlying driver or I am wrong here…
It can mean either thing.? When I think of “device emulation”, I think
about writing a driver for a piece of hardware that doesn’t exist.? So,
applications would use my driver as if the hardware were present, when
it was not actually there.? Usually, this is in anticipation of hardware
coming later, allowing us to test the application interface.
I have also done “device emulation” drivers where we were simulating the
addition of new features to an existing piece of hardware.? In that
case, the emulation driver might, indeed, pass some requests down to a
lower level, but provide the new functionality internally.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer