编辑：过时我并不是说不好/不必要（我同意/proc一团糟）。模块化是一件好事，我喜欢它。我的意思是：系统的信息，保存在（在/sys）其他地方可以找到。

我真的找不到太多关于/sys和 的信息/proc。除了这两个内容都不属于文件系统层次结构标准的一部分（因为它们看起来/正在构建的方式取决于内核版本）

/ SYS并不甚至有它自己的man页面。/proc 有它自己的手册页，哦，天哪，它有很多解释，但我仍然有一些文件夹和文件（例如/acpiand consoles），其中没有提到。 /sys很新吧？在它存在之前，所有提供的信息/sys都是/proc正确的一部分？

题：

现在还是这样吗？是否可以在一种或另一种形式中/sys找到所有信息/proc表？那会使文档/sys过时，因为它只是具有用户友好设计的扩展，对吗？或者是否有任何系统信息/sys不以其他形式存在/proc？

如果是这种情况，/sys向linux业余爱好者解释的地方在哪里？

以下两个文件是虚拟文件：

/dev/sda1
/proc/cpuinfo

我知道这/dev/sda1是一个设备文件（指向设备驱动程序），所以当我访问这个文件时，我实际上是在访问设备驱动程序。

但是/proc/cpuinfo，这个文件也是设备文件吗？如果是，Linux 设备文件中是否所有其他虚拟文件？

我的笔记本电脑有一个 SSD 驱动器，我运行一个脚本，每隔一秒写入一次/sys/class/thermal/cooling_device4/cur_state. 我不认为这会算作写入 SSD 并因此减少其剩余的写入周期数，因为procfs和sysfs是虚拟文件系统。

还是我忽略了一些东西，这是一个问题？

在安装 Linux 时，我只提到了一个文件系统（/dev/sda1 -> ext4 -> / ）。但是对于 dev、run、proc、sys - Linux 正在创建额外的 FS，这可以从mount.

$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=12138104k,nr_inodes=3034526,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=2433824k,mode=755)
/dev/sda4 on / type ext4 (rw,relatime,errors=remount-ro)
...

我知道 /proc 是一个虚拟文件系统，位于内存中，而不是在任何 HDD/SSD 上。有人可以解释一下 /dev、/run 和 /sys 的情况吗？它们是否存在于硬盘上（如果存在的话，如果可以有意义地追踪的话，其位置在哪里）。

基于已经问过的问题 -为什么 /dev 和 /run 的 inode 编号与 / 的 inode 编号相同？

据我所知，UDP数据包的接收流程是

1. 检查 udp 标头是否有错误
2. 将目的地与套接字匹配
3. 如果没有这样的套接字，则发送错误消息
4. 将数据包放入适当的套接字接收队列
5. 唤醒进程等待该套接字的数据

但在上述阶段，什么才算/proc/net/udp是下降呢？上述任一步骤失败是否构成掉落？或者仅当接收队列/缓冲区已满时才进行？

这是 shell 的 PID：

nathan@guixlaptop ~ $ $$
bash: 10984: command not found

我导出一个环境变量：

nathan@guixlaptop ~ $ export TESTVAR=test

在 shell 环境中找不到该变量：

nathan@guixlaptop ~ $ cat /proc/10984/environ | grep TESTVAR || echo "fail"
fail

如何让变量出现在环境中？

我正在学习 Linux procfs，它利用虚拟文件系统，其中open、read、write、 和 等操作release由注册到其中的函数处理。

我错误地将openandrelease保留为空指针，当我尝试读取文件的内容时，使用如下 Python 代码：

with open("/proc/testfile", "r") as f:
    content = f.read()

程序卡住了，我从内核 dmesg 中读取到空指针被取消引用的错误，这是预期的，因为它open指向 NULL。

然而，catGNU coreutils 的命令可以完成这项工作，给我输出如下

$ cat /proc/testfile
testoutput

这意味着cat没有调用该open函数而是直接调用read（write也可以这样做）。

根据我的理解，open()将返回一个文件描述符，该文件描述符进一步用于处理文件，并且read()需要文件描述符才能继续。

这在里面是怎么做到的cat？