extend windows ce platform with oalioctl

本文详细介绍了Windows CE平台中OAL IOCTL的功能特性,包括其灵活性、分离性和易用性。OAL IOCTL允许设备制造商轻松扩展内核功能,并使应用程序开发者能够直接访问这些新功能。
Though not being a open source platform, windows ce is designed to be flexible so that device venders can extend it easily. oalioctl is a feature that makes it possible to do things in kernel space on behalf of application.

Features
1. Extensibility
The essential feature of oalioctl is it enables us to extend windows ce kernel's functions, and new functions are directly accessible to application layer developers.
2. Separation
oalioctl is completely separated from kernel source code. From the sense of code organization, it doesn't differ from a normal device driver. The separation makes it easy to maintain and port oalioctl module.
3. Easy to use

Compared to a normal ce driver, the usage of oalioctl is easier from an application developer's perspective. In order to make use of a normal driver, application usually follows below sequence:
CreateFile -> DeviceIoControl -> CloseHandle
But the application can simply call KernelIoControl to make use of oalioctl library, which is a far more easy way.

Implementation
oalioctl is implemented as a standalone dynamic library. And it will be loaded automatically during kernel initialization (relevant code is in LoaderInit() function in X:/WINCE600/PRIVATE/WINCEOS/COREOS/NK/KERNEL/loader.c). So it's not necessary to register this module in platform.reg as other stream drivers do.
When an application calls KernelIoControl, the call stack goes like this:
IOControl //our own oalioctl.cpp
OEMIOControl  // platform/common/src/common/ioctl/ioctl.c
IOControl // public/common/oak/oalioctl/oalioctl.cpp
EXTKernelIoCtl // private/winceos/coreos/nk/kernel/kwin32.c

How to implement our own oalioctl
It's a fair simple task to implement oalioctl layer for our own platform with following steps:
  1. copy public/common/oak/oalioctl directory to platform/platform_name/src/drivers
  2. change TARGETTYPE to DYNLINK in sources file
  3. define our own iocontrol code with CTL_CODE macro
  4. add a case branch for the new iocontrol code
### 错误分析 在PyTorch中,`torch.nn.ModuleList` 是一种特殊的容器类,用于存储多个 `nn.Module` 子模块。当尝试向 `ModuleList` 添加新子模块时,如果传递的对象不是可迭代的,则会引发错误:“`ModuleList.extend called with non-iterable`”。此错误表明传入的方法参数不是一个有效的可迭代对象。 通常情况下,这种错误可能由以下几个原因引起: 1. **非列表/元组类型的单个对象**:如果试图将单一的 `nn.Module` 实例而不是包含这些实例的集合(如列表或元组)传递给 `.extend()` 方法,则会发生此类错误[^1]。 2. **数据结构不匹配**:即使提供了某种形式的数据集合作为输入,但如果该组合本身不可迭代或者其内部成员不符合预期类型也会触发异常情况[^2]。 为了修复这个问题,应该确保总是把一个真正的 Python 可迭代序列作为参数提供给 `ModuleList.extend()` 函数调用;也就是说要么是一个标准意义上的 list 或 tuple ,其中包含了若干待加入到 ModuleList 中的具体 module 对象实例们。 以下是具体的解决方案以及如何正确实现的例子: ```python import torch.nn as nn class MyModel(nn.Module): def __init__(self): super(MyModel, self).__init__() # 正确做法: 使用list/tuple等可迭代对象初始化module_list modules = [nn.Linear(10, 10), nn.ReLU(), nn.Linear(10, 5)] self.module_list = nn.ModuleList(modules) model = MyModel() print(model) ``` 以上代码展示了如何通过创建一个包含所需层的列表来避免这个常见陷阱,并将其赋值给继承自 `nn.Module` 的类中的属性变量 `module_list`. 另外需要注意的是,在动态构建网络架构过程中可能会遇到类似的场景——即根据条件决定是否增加某些特定操作至模型之中。此时可以考虑先收集所有必要的组件进入临时缓冲区后再统一添加进去,如下所示: ```python temp_modules = [] if condition_1: temp_modules.append(some_module_instance_1) if condition_2: temp_modules.append(some_module_instance_2) ... final_model_part = nn.Sequential(*temp_modules) # or use another container like ModuleList ``` 这样不仅可以保持逻辑清晰易懂而且有效预防了由于单独处理而可能导致的各种潜在问题.
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值