Wince6.0 driver porting (driver model change, and comparison with wince5.0)

Wince6.0 driver transplantation (driver model changes, and compared with wince5.0) from: http://chenyq2008.spaces.live.com/blog/cns! F74254ac8d0d8d50! 205. Entry Chen Yongqiang [Device Manager]

The device management code is in the private \ winceos \ coreos \ device \ directory. the wince6.0 on the right omitted Inc, irom, nopmif, and pmif4 directories. these directories are header files, IO resource management, and power management interfaces.

Look at the Device Manager entry point devmain. c. in the wince5.0 era, the Device Manager is implemented as a process: devece.exe. so it is an entry function winmain () that calls the startdevicemanager () function. let's look at wince6.0 and devmain. C has more devmainentry (), dllentry (), aha ~ It seems that the Device Manager is also suffering from the fate of kernel. It has become device. dll.

[Device Driver loading process]

Oal.exe loads kernel. DLL, kernel. DLL load device. DLL, device. DLL load devmgr. DLL, which is responsible for loading, detaching, and managing the stream driver. the process has been compared for half a day. There is no difference between the driver loading process of wince6.0 and the loading process of wince5.0. it can also be divided into static loading and dynamic loading. static Loading is loaded at startup. find the busenum under HKLM \ drivers \ builtin in the Device Manager. DLL loading. This is a bus enumeration driver. It completes subsequent loading according to the order value. It also uses activedevice to load. dynamic Loading means to use activedevice to load a driver after the system is up. after the device is loaded, the device information is also displayed under the Active Directory of the Registry.

The information required by the driver in the registry is basically the same, which is also prefix, DLL, index, order, iclass. The key difference lies inFlags, userprocgroupThese two keys.

[Flags: Driver loading configuration]

Each driver in the Registry can contain a key flags. This configuration determines the driver loading. The following is an optional configuration of flags of wince5.0. (multiple phases can be used to obtain a composite value:

Devflags_none

Flags is not specified in the registry.

Devflags_unload

Indicates that the Device Manager disconnects the driver after init is executed, and returns a successful result. The driver for bus enumeration does this.

Devflags_loadlibrary

The difference between notifying the Device Manager to use loadlibrary instead of loaddriver.2: loadlibrary can load paged out.

Devflags_noload

Indicates the Device Manager. The driver will not be loaded.

Devflags_nakedentries

Indicates that the Device Manager prefix is not used. you can use the prefix to activate the function, but do not use the prefix to locate the function entry point. for example, if the battery driver specifies this identifier, the Device Manager uses the bat prefix to implement the driver. However, bat_init is not used by default when an interface is called ,. bat _ ***. Instead, you can find the entry point on your own. the purpose is to freely modify the name of the driver interface function. Do not use the same prefix.

Devflags_bootphase_1

The bootphase must be greater than 1. bootphase indicates the startup phase. the Device Manager is started in stages. bootphase1 is looking for the Registry .; bootphase2 loads the driver, and bootphase3 starts to run. (The problem can also be divided into two stages .)

Devflags_irq_exclusive

Load again when accessing IRQ.

Wince6.0 adds several

Devflags_load_as_userproc

This is the first scene,Indicates the Device Manager.,Load the driverUser mode.The Device Manager createsReflector.This isWince6.0Major improvements.I don't know either.,Let's talk about this later..

Devflags_nounload

Prevents the driver from being detached.

Devflags_trustedcallreronly

Instruct the Device Manager to restrict the driver to only trusted application open. This is also described in wince5.0, but it is not found in the code, so 5.0 should not be implemented. (Space-Time Disorder? Or document design first? Ms is still hiding private goods, but my version does not exist .)

[Driver Model]

Does the driver model of wince6.0 remain unchanged? Compared to wince5., all the drivers are loaded by device.exew.gwes.exe. In wince6.0, these two do not exist, and the dllis loaded by nk.exe. The natural idea is that all drivers are routed to the process space of nk.exe? That's all?

In any case, start the simulator and check that the wince6.0 device only hasNk.exe, shell.exe, servicesd.exe, assumer.exe, 4ItemsUdevice.exe. Hum ~, No more device.exe is available. The package includes filesys.exe, gwes.exe, and so on ...... After a while, the DLL. udevice.exe loaded by nk.exe is changed to four! Intuition is driving. What changes do these phenomena reflect in the driving model?

The RegistryFlagsDifference and AdditionUserprocgroup. Flags addedDevflags_load_as_userprocThis option instructs the Device Manager to load the driver into the user mode driver. Then, let's take a look at the pseudo code of startdevicemanager () in devcore. C:

 

Startdevicemanager ()

{

Initialize device data structure, enable IO resource management, PNP device management, and Power Management

Devloadinit (); // load the device driver here.

Inituserpromgr (); // new in ce6. initialize user mode driver handling.

While (1)

{

Processautoderegisterdevs ();

Processdyingdevs ();

Processdyingopens ();

}

}

 

Hmm ~ It seems that the user mode driver is also supported. Since it is called user mode, it is definitely not in the kernel space, not in the nk.exe space. Find the figure below, which is simple and clear.

The Device Manager will followDevflags_load_as_userprocOfIndicates creating a new process to load a driver. This process is completed by udevice.exe. Four udevice.exe.udevice.exe on the upper left side of the simulator, which contains a group of user-mode driver DLL ~ A process can indeed load multiple DLL files. But which user modedrivers will be merged to a udevice.exe? You can just guess it.UserprocgroupThis key acts as a driver group for the user mode. Attach the same group to a process. well, by the way, the user mode driver hostname in the manual is invalid. The user mode driver sender is udevice.exe.

How to group data? What is the value of userprocgroup? Look at the registry:

[HKLM \ drivers \ procgroup_0002]

Procname=”servicesd.exe"

Procvolprefix = "$ Services"

Proctimeout = 20000

[HKLM \ driver \ procgroup_0003]

Procname=”udevice.exe"

Procvolprefix = "$ udevice"

Haha ~ The logic is very simple. Create a group here, such as 0003. If you want to join this group, set userprocgroup to 3. 0003 indicates the code, not three drivers. procname indicates the name of the host process that loads the driver. the original udevice.exeand servicesd.exe processes are like this.

To sum up, if flags is not specifiedDevflags_load_as_userprocThe driver will be redirected to nk.exe, that is, the kernel mode driver.exe. If specified, the driver will be redirected to udevice.exe as the user mode driver. A udevice.exe can load multiple user mode drivers or only one.