Differences between kerneliocontrol functions 5.0 and 6.0

In the oal part of the BSP of wince, there will be an IOCTL. C or oemioctl. c file, which mainly defines a function called oemiocontrol. It can be said that oemiocontrol is

A very useful wince Kernel Input/output function.

In wince5.0, the applicationProgramAnd the driver can access the wince kernel by calling the kerneliocontrol (...) function, resulting in calling the oemiocontrol function.

And the driver can access the resources in OAL. However, wince6.0 provides better security, and applications are limited to access the case in oemiocontrol,

Only the following cases can be accessed by the application:

Ioctl_hal_get_cache_info
Ioctl_hal_get_device_info
Ioctl_hal_get_deviceid
Ioctl_hal_get_uuid
Ioctl_processor_information

If the user tries to access other cases in the application, it will certainly return failure. In wince6.0, the driver can also access any

Case. Some may ask, how can we allow applications to access some cases ??

There are still some solutions. Check wince600/public/common/oak/oal/IOCTL/oalioctl. C. This file defines the case that the application can access and

The case to be accessed by the application can be added to the iocontrol (...) function in this file. Of course, you need to re-compile the public directory.

In wince5.0, The oemiocontrol function is defined in the oal part of the BSP. As mentioned above, it should be IOCTL. C or oemioctl. C. But in wince6.0, this

The function definition has been moved to wince600/platform/common/src/common/IOCTL. C. The oemiocontrol function and the previous one have also changed.

Query a table: g_oalioctltable []. This table is actually a structure array that defines all cases in oemiocontrol. The processing function for this case has also included a flag for each case. This flag indicates whether to use critical zone protection. The specific definition is as follows:

Typedef struct {
Uint32 code;
Uint32 flags;
Bool (* pfnhandler) (uint32, void *, uint32, void *, uint32, uint32 *);
} Oal_ioctl_handler, * poal_ioctl_handler;

Therefore, in the BSP of wince6.0, we only need to implement g_oalioctltable. For example:

Const oal_ioctl_handler g_oalioctltable [] = {
{Ioctl_hal_postinit, 0, oalioctlhalpostinit },
{Ioctl_hal_get_hive_clean_flag, 0, oalioctlhalgethivecleanflag },
{Ioctl_hal_get_hwentropy, 0, oalioctlhalgethwentropy },
{Ioctl_hal_get_image_signed_state, 0, oalioctlhalgetimagesignedstate },
{Ioctl_hal_query_format_partition, 0, oalioctlhalqueryformatpartition },
{0, 0, null}
};

In the oemiocontrol function, we should not only implement the case in oemiocontrol, but also define some global oal variables:

G_oalioctlclockspeed this global variable contains information about the processor clock speed.
G_oalioctlinstructionset this global variable contains the processor instruction set identifier.
G_oalioctlplatformoem this global variable contains information about the hardware platform OEM.
G_oalioctlplatformtype this global variable contains information about the hardware platform type.
G_oalioctlprocessorcore this global variable contains information about the processor core.
G_oalioctlprocessorname this global variable contains information about the processor name.
G_oalioctlprocessorvendor this global variable contains information about the processor vendor.

In fact, there are some hardware and platform-related information. Just define it.

Sometimes we want to add our own case in the oemiocontrol function according to our specific needs. This is relatively simple. We only need to define a case and then write your

ImplementationCodeThen, the driver calls the same case through kerneliocontrol to call the case defined in oemiocontrol. Case worth defining: 1.

In general, it will be safer Between 2048 and 4096. I remember that in wince6.0, it would be okay to check that Microsoft's code is more than 256. I have not tried it yet. If I had insurance, I would still use 2048.

The above values.