Module类和接口关系

1.Module:

实现:IModel

2. IModule

将类标记为模块的接口。

3.IFlexModuleFactory 

实现:SystemManager(SystemManager 类管理应用程序窗口);SystemManager 是在应用程序中创建的第一个显示类。它负责创建要显示的 mx.preloaders.Preloader 以及应用程序完成加载时显示的mx.preloaders.SparkDownloadProgressBar,然后创建 mx.core.Application 实例。

IFlexModuleFactory 接口提供引导 Flex 应用程序和动态加载的模块时应该使用的约定。

4.ModuleLoader

ModuleLoader 组件的行为方式与 SWFLoader 极为相似,不同的是它需要遵循与加载内容间的合同要求。本合同规定子级 SWF 文件实现 IFlexModuleFactory,并且可以按需使用实现的 factory 创建子类的多个实例。

5.ModuleManager

ModuleManager 类会集中管理动态加载模块。并会维持 URL 到模块的映射。模块可以处于已加载(并且可使用)状态,也可以处于尚未加载状态。ModuleManager 会分派显示模块状态的事件。客户可以注册事件处理函数,然后调用 load() 方法,该方法可在 factory 就绪时(或者,在已加载时可立即)分派事件。

Module和ModuleManger的区别:

ModuleLoader

Flex中的ModuleLoader组件为模块的载入提供和很方便的接口,它是高层的处理Module的API。

可以这种在flex中简单的使用module

<mx:ModuleLoader url="MXMLDemoModule.swf"/> 

也可以在编程时动态的改变URL,来加载不同的Module。

ModuleLoader其实是一种特殊的导航式容器。和一般导航式容器如ViewStack不同的是,ModuleLoader不必在初始化时携带加载所有的孩子组件。

另外,推荐在moduleloader做切换的时候,加上:moduleLoader.unloadModule再做moduleLoader.loadModule()。Flex确保调用load()方法只有一个对象。

ModuleManager

ModuleManager类提供了低层次的处理Module的装载卸载以及事件响应等的变成接口。这种方式比起纯粹的ModuleLoader方式稍微复杂一点,但是ModuleManager提供了比ModuleLoader更加强大的能力来管理Module模块的加载过程。

 具体操作可以分成以下几步:

1.通过ModuleManager实例的getModule()方法拿到Module模块的一个索引,索引类型为IModuleInfo。 

2.调用这个索引的load()方法。 

3.利用这个接口的factory属性拿到它相关连的Module工厂,调用此工厂的create()方法,并将返回值强制转换成当前的Module类型。

private var module:IModuleInfo;   

       module = ModuleManager.getModule("UserList.swf");   

       module.addEventListener(ModuleEvent.READY,onModuleReadyUseModuleManager);  

       module.load();   

      private function onModuleReadyUseModuleManager(event:Event):void{     

                 var me:ModuleEvent = event as ModuleEvent;     

                 userList = me.module.factory.create() as UserList;         

                 container.addChild(userList);  

 }  

 在调用create()方法的时候,可以先不加入显示列表,这样就可以先将module载入内存,需要的时候再加入显示列表。

加载过程的事件

 这个倒不是ModuleManager特有的,ModuleLoader也有,就是setup,ready,unload,progress,error等事件。

 Progress事件

protected function onModuleProgress (e:ModuleEvent) : void {    
                trace ("ModuleEvent.PROGRESS received: " + e.bytesLoaded + " of " + e.bytesTotal + " loaded.");   
      }  
主要就是bytesLoaded和bytesTotal,分别表示已经加载的字节数和总共的字节数。


<think>嗯,用户这次问的是Linux内核中module_platform_drivermodule_init之间的关系与区别,这是个很具体的驱动开发问题。结合用户之前的提问记录,ta似乎正在研究内核模块的加载机制,而且已经查阅过平台驱动的实现示例。用户提到的两个宏确实容易混淆。module_init是内核模块的通用入口点,而module_platform_driver是专门为平台驱动设计的简化宏。从ta给出的代码示例看,在平台驱动场景中基本都会优先使用后者。考虑到用户可能正在写驱动,需要明确使用场景:-当开发标准字符设备/块设备驱动时,仍然需要module_init配合自定义初始化函数-但如果是访问内存映射IO资源的平台设备,用module_platform_driver可以省去大量模板代码特别要注意的是驱动加载顺序问题。在之前的代码示例中,platform驱动都是最后执行的,因为businitcall优先级更高。如果用户错误地在非平台驱动中使用module_platform_driver,可能会导致设备资源未被初始化就尝试probe的灾难性后果。用户贴出的引用文献里,第二篇关于bus_type匹配机制的内容很有价值,应该引用在回答里说明为什么平台驱动需要特殊处理。另外可以结合内核源码片段展示这个宏的展开过程,这样更直观。对于进阶问题,用户可能还想知道如何修改初始化优先级,或者混合使用两种机制的情况。这些问题可以作为补充内容放在最后,毕竟ta的关注点主要在区别而非高级用法。</think> `module_platform_driver` `module_init` 都是 Linux 内核驱动程序的入口点声明宏,但面向的场景抽象层级不同: --- ### 核心关系与区别 | **特性** | `module_platform_driver` | `module_init` | |-------------------------|----------------------------------------------|------------------------------------------| | **用途** | 专为 Platform Bus 驱动设计的**简化宏** | 通用内核模块的**标准入口宏** | | **内部实现** | 封装了 `module_init` `module_exit` | 直接定义模块的初始化/退出函数 | | **适用对象** | Platform Driver (`struct platform_driver`) | 所有型驱动(字符设备、块设备、平台设备等)| | **初始化逻辑** | 自动注册 Platform Driver 到 Platform Bus | 需手动调用总线注册接口(如 `platform_driver_register()`)| | **资源管理** | 隐含总线匹配设备树支持 | 需开发者自行实现匹配逻辑 | --- ### 源码级关系解析 #### 1. **`module_platform_driver` 本质是 `module_init` 的封装** 展开宏定义(Linux 5.10+): ```c // 简化为: #define module_platform_driver(__platform_driver) \ module_driver(__platform_driver, platform_driver_register, \ platform_driver_unregister) ``` 其中 `module_driver` 进一步展开: ```c #define module_driver(__driver, __register, __unregister) \ static int __init __driver##_init(void) \ { return __register(&(__driver)); } \ module_init(__driver##_init); \ // ... 对称定义 module_exit ``` 最终仍通过 `module_init` 注册初始化函数[^2]。 --- #### 2. **使用场景对比** ##### 标准 Platform Driver 写法(用 `module_platform_driver`) ```c static struct platform_driver my_driver = { .probe = my_probe, .remove = my_remove, .driver = { .name = "example" } }; module_platform_driver(my_driver); // 一行搞定 ``` ##### 等效的手动实现(用 `module_init`) ```c static int __init my_init(void) { return platform_driver_register(&my_driver); // 需手动注册 } module_init(my_init); static void __exit my_exit(void) { platform_driver_unregister(&my_driver); // 需手动注销 } module_exit(my_exit); ``` --- ### 关键流程差异 ```mermaid graph TD A[内核加载模块] --> B{入口声明方式} B -->|module_platform_driver| C[自动注册到Platform Bus] B -->|module_init| D[需调用注册函数] C --> E[总线触发设备匹配] D --> F[需手动调用如 platform_driver_register()] F --> E E --> G[执行probe函数] ``` --- ### 何时选择? | **场景** | **推荐宏** | |-------------------------------|--------------------------| | Platform 设备驱动开发 | `module_platform_driver` | | 非总线型驱动(如纯字符设备) | `module_init` | | 需自定义初始化流程 | `module_init` | | 标准 Platform 驱动开发 | `module_platform_driver` | --- ### 典型问题分析 **Q:混用二者导致重复注册?** 若在 Platform 驱动中同时写: ```c module_platform_driver(my_driver); module_init(my_init); // 错误!导致platform_driver_register()被调用两次 ``` 将触发内核错误:`platform_driver_register() failed with -EEXIST`。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值