I got some feedback while I was in Vegas attending MEDC 2007..
I might not have been clear in my presentation but the CE 6.0 Kernel will validate first level pointer parameters for you. It knows the signature of the API (and can verify the first level buffer being passed to the kernel driver.
You as a driver developer, only have to Access Check embedded pointers; embedded pointers are pointer parameters that are passed to your driver by storing them within the first level buffer - Actually you can view this recursively and can have nested buffers.
The kernel while checking the first level parameter has no idea of what the 4 bytes stored with the buffer means to the driver - it could be a DWORD for all it cares; it all depends on how the kernel driver is going to interpret these 4 bytes - and thus, It
is the responsibility of the driver to access check embedded buffers because such embedded buffers could be pointing to memory that the caller does not have access to.
Porting 5.0 BSP's to 6.0 requires some work but its something that can be done quite easily. I will probably do a demo so that you get the overall picture of what was changed and how you can get your porting done right away.
The number of drivers really depend on the CE Device you are building or refering to. But on the general, a CE device will have some Storage/block driver, some networking driver(s), probably an Ethernet Debug one, soemtimes USB and SD/SDIO, Audio for others
and Display/Video for those with screens and soetimes with Touch for touch capability. In addition I have seen PCMCIA/PC Card, Keyboard, Mouse Input drivers, Serial/Parallel so you can see exactly how the average is so hard to define across the numerous different
Is there any particular information you are tryign to gether that I might be able to help with?
1) Cool idea, the white board is quite clear in reality. The camera capture might need to tweaked.
2) Right the notion of synchronous and asynchronous here might be confusing, but of highly important value and so I will clarify here:
When porting your drivers to CE 6, if the driver is going to access the caller's buffer on the caller's thread, then it falls under the synchronous access arena and you dont have to do any marshalling since the kernel driver can access the caller's buffer directly.
That is to say that the kernel guarantees that the caller's process is mapped when the caller's thread is running and hence the kernel driver can be sure that it is accessing the correct buffer when doing so on the caller's thread.
If on the other hand the driver is going to access the caller's buffer on a thread that belongs to some other process, say the kernel, then it falls under asynchronous arena and the driver has to marshall the buffer using the marshalling APIs so that the kernel
driver has a local copy of the buffer that can be accessed when needed on any thread
The marshalling need here arises from the fact that you cannot be sure of the user process mapped when accessing the caller buffer on some other thread. And so, you have to marshal the buffer initially on the caller's thread to get a local copy for future use.
The local buffer can then be accessed by any other driver thread and upon completion needs to call the right API to free up the local buffer and to copy back the buffer to the caller's process.
Let me know if this helps - else I will put up some diagrams to illustrate this clearly
3) Thank you for your kind words. And thank you for your patience in listening and understanding these complex concepts.
We have been working hand in hand with Peter Wieland to make sure our technologies align well. That said, drivers today on the desktop and CE are of different forms and whenever we think of introducing WDM compatibility for CE, we always wonder if there are
a ton of chips shared across the two platforms and the ROM Size implications
Rest assured, we are always working to get the best for our customers for all platforms