蜗窝科技

@linuxer：这里的SOC具体是什么含义呢？目前按照arch/arm来分，也有一定的合理性，因为有很多ARM相关的很新代码，是共用的。

@Daniel Shieh：欢迎Daniel。 做过一点点，但不是很深入。

注册了账号了，博主做没做过Android方面的东西呢？

有点歪楼哦，本文的主题是电源管理，呵呵～～～不过我喜欢这个话题 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 实际上，按照arch/SOC/board这样的代码组织是否OK？对于很多的ARM soc，其实它的很多controller都是购买的，例如USB OTG controller，可能都是购买自同一家公司。而目前的ARM的代码组织导致很多的代码重复。 也许确实应该从功能角度进行目录规划......

@有理想的咸鱼：确实，arch/arm目录是很凌乱的。所以那些概念性的东西，如Architecture，如Machine，其定义也不是很清晰。我们看内核的时候，不要太纠结这些词汇就是了。

纯技术性博客..看不懂 顶一个 哈哈

针对5.1 section，我的看法如下： 实际上，硬件是分三个层次： 1、用的哪一类型CPU，是X86的还是ARM的（对应linux kernel中的arch/XXX目录） 2、如果使用的是X86的CPU，那么具体使用哪一种CPU，是AMD的Geode 处理器还是intel的mid处理器。如果是ARM，那么使用的是S3C2410还是OMAP3530（在ARM中，我看不出什么对应关系。对与X86平台，对应linux kernel中的arch/platform/XXX目录） 3、具体的target board。这个是和具体的项目相关，和CPU以及周边的外设相关。具体的target board必须要选择一个CPU platform以及外设芯片（对应linux kernel中的driver目录）。而描述board相关的信息对应对应linux kernel中的arch/platform/XXX/board-xxx.c文件。 对于arch/arm目录下的东西，非常凌乱，希望近期的kernel release能够改善。我理想的目录结构是： 1、arch保持不变，映射CPU architecture的概念 2、建立platform目录，映射CPU platform的概念。 3、选择了某个CPU platform的target board代码应该尽量的少（和CPU platform相关的代码是公共代码，并非board specific，和外设相关的代码在driver目录）并集中在一个文件（我看不出来这个board specific文件存在的必要性，可能有些board fixup吧）。 Machine的概念在ARM上比较模糊。在定义每一个SOC的时候，使用了ARCH这个术语，例如对于Marvell的PXA2xx/PXA3xx-based的CPU platform，arm kernel使用了ARCH_PXA这样的定义，而在board specific文件，例如mainstone.c中，我们需要定义一个MAINSTONE相关的MACHINE。linus大骂ARM linux的代码“this whole ARM thing is a f*cking pain in the ass”也是有些道理的。

@Daniel：一般需要用一个订阅工具，例如我现在使用的FoxMail邮箱，或者以前的Google Reader，然后在添加订阅时，输入RSS的地址，如“http://www.wowotech.net/rss.php”，就可以了。

@蜗蜗：订阅好像有问题，点击订阅，出来的是源代码

@Daniel：写书是这样的过程，你自己是一个装满水的水库，但是准备了一桶水，给读者倒了一杯。但现在，我们只是建好了水库，还在蓄水阶段......