关于FAL+FMD的网摘

块设备驱动从字面上来看，它是以块即block为单位进行读取的流式设备驱动。
因为属于流驱动范畴，所以也是XXX_Init XXX_Read XXX_Write XXX_IOContorl的接口形式。
但是这种驱动往往用于存储设备，所以一般是冠以DSK_的prefix，而且它会有一个固定的ICLASS={..... .....}，你随便找个sample看看就晓得了。所有的块设备驱动会在被设备管理器加载后被存储管理发现，因为它的ICLASS会让device.exe偷偷告诉filesys.exe有活干了，后者通知下属存储管理去加载块设备驱动所注明的文件系统并且mount上存在存储设备上的分区。
块设备驱动的IOContorl里面一般都会有固定的Read和Write的IOCTLCODE，上层的文件系统或其他middleware会通过这两个接口来存取数据，存取的最小单位是block，默认为512bytes。得益于块驱动的固定接口模型，方便系统在设计上层文件系统和其他middleware的时候具有最大的平台移植性。举例来说，SD卡和Nand虽然驱动不同，但是因为对外提供的接口都是块设备接口，所以文件系统都可以识别并且加载它们，就算你换到其他的SOC平台，文件系统和存储管理也不需要改变。块设备上层也可以不是文件系统，举个middleware的例子就是当device做massstorage client使用的时候，USB client驱动会直接访问块设备驱动接口，提供给USB host那段的数据访问服务。
在CE里面，块设备驱动有自己的专属类别（ICLASS），CE会把具有块设备驱动的ICLASS的驱动和普通设备驱动区分对待。比如电源管理中，块设备驱动必须在suspend过程中最后一个进入电源节省状态，而在resume的时候第一个进入电源恢复状态，以保证系统的正常运行（因为类似binfs的文件系统，都是建立在块设备驱动基础之上，基础不能work后上层建筑就挂了）
你的问题是FAL+FMD是否是块设备驱动？
答案是是块设备驱动，FAL+FMD是微软的NAND驱动的架构，类似于MDD+PDD，FAL+FMD整体上实现了一个完整的块设备驱动，当然按照微软的习惯，对外的流接口和与平台无关的逻辑层一定会放在MDD层也就是FAL层去实现，而和硬件平台有关的控制器的驱动就是FMD了。