现在的嵌入式系统从内而外一般是 CPU -> SoC -> Board。
我的设想是，内核提供CPU级的支持，SoC厂家提供on-chip driver（这可以放在内核中），外设的驱动都交由开发板或者商业产品的开发团队自己去做。
产品开发人员根据自己选用的外设，如LCD面板、Camera Sensor、Ethernet PHY等编写对应的外设驱动，然后在应用启动时自己控制外设驱动的加载和on-chip驱动的加载，以及外设驱动和on-chip驱动的交互。
这么做的结果是可以提供一个统一、固定的平台给产品开发人员，产品开发人员不需要管内核的事，最多修改一下运行时配置文件，如GPIO分配。这可以降低系统和应用的耦合度，加快产品开发。
离线
微内核和宏内核之争。楼主说的应该是微内核架构。
Linux的老师开发了个微内核Unix系统叫什么我忘了，还挺有名
离线
达克罗德 说：微内核和宏内核之争。楼主说的应该是微内核架构。
Linux的老师开发了个微内核Unix系统叫什么我忘了，还挺有名Minix ?
对，就是这个。 http://www.minix3.org
离线
有外设全部在用户态的系统，qnx, 但是不开源而且收费很贵
离线
这似乎不关“驱动是否要放用户态”的事吧？
BSP包完全可以独立出来开发的：device tree能单独编译，自定义的驱动能编译成内核模块，只在编译的时候借助下内核的构建系统。
楼主的需求是否只是想 “分清内核、驱动、应用之间的开发界限，降低互相间的耦合” ？
其实，内核对设备的抽象做了不少工作了，很大程度降低了应用层使用具体设备的复杂度。
应用通过统一的devfs、sysfs或者proc来与驱动进行交互。从结果来看，就是降低了应用与驱动之间的耦合。
楼主所提的 “提供一个统一、固定的平台给产品开发人员” 需求 ，只要保证 “同类设备，保持统一规范的devfs、sysfs、procfs的访问接口” ，即可满足。
楼主又提到 “应用启动时自己控制外设驱动的加载和on-chip驱动的加载，以及外设驱动和on-chip驱动的交互”，这只能是基于内核托管的情况下才能部分实现，还是以内核模块为单位的简单管理。更细粒度的管理，应用层 ‘不应’ 也不能直接去触碰。驱动涉及到的资源协调和配置都应该是OS一级去处理的事，而不是一个以进程为单位的APP该操心的事。
linux 把驱动拉到内核态，是为了最大化运行效率。qnx 为代表的微内核把驱动之类的做到用户态，是为了运行时的稳定而牺牲了运行效率。
这是个不同场景利弊取舍的事，也不能一下子分清哪种做法就一定是好的。
但不论驱动放在何处，其与应用层之间的接口保持统一和固定了，就能给开发人员提供一个稳定的开发环境。
离线