Linux - procfs

Here is the precise breakdown of how the /proc virtual filesystem maps to the underlying kernel objects.

Is /proc just another view of task_struct?

• Conceptually: Yes.
• Technically: It is a dynamic view of the entire kernel state, organized around tasks.

The /proc filesystem is a virtual filesystem (procfs). It does not exist on disk; instead, the kernel generates its contents on the fly when you read from it. While a massive portion of /proc is dedicated to processes (which are represented by struct task_struct), /proc also contains system-wide information completely unrelated to specific tasks, such as:

• /proc/meminfo (maps to global memory statistics via struct sysinfo)
• /proc/cpuinfo (maps to CPU architecture parameters)
• /proc/sys/ (maps to kernel sysctl variables)

So, it is more accurate to say that the /proc/[pid] subdirectories are an alternative view of the system's task_struct array.

Is each /proc/[pid] backed by one struct task_struct?

Yes. Every directory named after a number (the Process ID, or PID) inside /proc directly corresponds to exactly one struct task_struct currently managed by the kernel's scheduler.

• The Connection via pid_namespace: When you look inside /proc, the procfs code iterates through the kernel's PID hash tables (specifically looking at the current pid_namespace).
• The Lookup: When you access /proc/1234/, the kernel looks up the PID 1234. If found, it fetches the corresponding task_struct pointer.
• The Lifespan: If a process exits, its task_struct is reaped by its parent, and that specific /proc/[pid] directory instantly vanishes from the filesystem view.

Is each /proc/[pid]/fd/[fd] backed by one struct file under the task_struct?

Yes, but via an intermediate descriptor table structure.

The data path from /proc/[pid]/fd/[fd] down to the actual file on disk goes through a specific chain of pointers inside the kernel. It does not sit directly inside task_struct.

The Nuance: Shared File Tables (Threads)

Because of the intermediate struct files_struct pointer, multiple task_struct objects can point to the exact same file table.

When a process creates lightweight threads using the clone() system call with the CLONE_FILES flag active, the kernel creates a new task_struct for the thread, but copies the pointer to the parent's files_struct. Therefore, /proc/[parent_pid]/fd/3 and /proc/[thread_pid]/fd/3 will resolve back to the exact same underlying struct file.

Is ps just another view of /proc?

Yes, ps is strictly just another view of /proc. On a Linux system, the ps command does not use specialized kernel backdoors or private system calls to grab process statistics; it gathers 100% of its process information by parsing text files inside /proc