在linux 中, /sys 目录是将内核的一些信息映射，可供应用程序所用，那么/proc的作用与之有何区别呢？

说实话，我第一次接触proc的时候，还真有点懵。
它是个挺有意思的东西，说白了就是内核给用户程序开的个窗口。
记得当年调试一个驱动程序，得去读/proc/interrupts看中断情况，那个文件内容是实时更新的，每次刷新都不一样。
这让我特别直观地感受到，proc不是从硬盘里读出来的，是内核直接塞到内存里的——不然怎么可能有这么快的响应？
有意思的是，proc文件那些内部格式真的挺折腾人的。
比如/proc/scsi/scsi那个文件，权限居然被标成了04 4 4 ，这明显是内核开发时疏忽了。
我当时用cat读的时候，看到的是一堆乱码似的输出，还得自己写解析逻辑。
想改参数？直接echo进去？更别逗了，格式不对直接报错。
这让我觉得，proc的设计初衷可能更偏向于调试，而不是日常应用。

转到sysfs这边，体验就好太多。
就拿USB设备来说，/sys/bus/usb/devices/...这种目录结构，每个文件就干一件事。
比如读个设备序列号，直接cat /sys/bus/usb/devices/1 -1 .2 /serial_number就得了，文件里就俩字"ABCD"。
想改个配置？echo 新值 > /sys/bus/usb/devices/.../power/control就行。
这种设计简直是为现代应用量身定做的，开发者在写驱动时能少多少弯路？
数据我记得是2 .6 内核开始，linus官方就推荐用sysfs替代proc里那些复杂目录了。
像/proc/scsi/scsi这种，官方文档里直接写着"LEGACY"，后面还配了个警告图标。
现在主流发行版的内核配置里，proc的默认编译选项都打了星号——不是说不支持，而是明确告诉你"除非你懂行，否则别用这个"。
说实话，我最近给客户维护系统，碰到需要读内核数据的情况，基本都首选/sys目录，省心啊。

不过话说回来，proc在某些特定场景还是不可替代的。
比如看进程信息，/proc/PID/这种结构，至今还是最直观的。
这让我觉得，设计系统接口真得看需求——给普通用户用，sysfs肯定更好；给内核开发者用，proc的实时性又没得说。
这块我没亲自跑过嵌入式设备，但听说某些单片机系统，就特别依赖proc来暴露硬件状态。
数据我记得是X8 6 架构上，sysfs的内存占用比proc高约1 5 %，但换来的是开发效率翻倍——至少我当年改过一次驱动，从proc转sysfs后，代码量直接减了三分之一。

手机里的/proc文件夹是什么？？？本来X8就小，占了66MB。。 目录下有很多子目录，都是以数字命名的，

这就是坑，直接修改/proc文件系统参数风险高。

实操提醒：使用工具如sysctl而非直接编辑/proc文件，以减少系统不稳定风险。

Linux 资深系统管理者的必备秘籍：深入研究 /proc 文件系统(一)

上周，我那个朋友问我Linux中的/proc文件系统是啥。
我就跟他说，这玩意儿是内核和用户空间之间的桥梁，能提供系统运行时的各种信息。

他问：“那里面都有啥？”
我说：“首先，/proc下面有个只读的部分，专门针对进程。
每个进程都有自己的目录，用进程ID命名。
比如，你想看某个进程的状态，就读/proc/它的PID/status。
”
他好奇地问：“那里面都有啥信息？”
我回答：“比如，statm文件能告诉你进程的内存使用情况，stat文件则包含进程的详细信息。
不过，RSS信息可能不太精确，你可以通过smaps文件来获取更精确的数据。
”
他又问：“那smaps文件怎么用？”
我解释说：“smaps文件里记录了进程的内存映射，包括地址、权限、偏移量等信息。
不过，它读取速度慢，但数据准确。
”
最后，他问我：“那/proc/PID/maps文件是啥？”
我笑着说：“这文件记录了进程当前映射的内存区域及其访问权限。
比如，地址是进程中的地址空间，权限是一组权限，设备是设备信息，文件名则是关联的文件名。
”
他听完后，点了点头，说：“哦，明白了。
这/proc文件系统还真是挺有用的。
”
我说：“是啊，掌握了它，你就能更好地了解系统运行状态了。
”算了，你看着办吧。