cultureoreo.blogg.se - Bash return proc cpuinfo

BASH RETURN PROC CPUINFO DRIVERS
BASH RETURN PROC CPUINFO DRIVER
BASH RETURN PROC CPUINFO CODE
BASH RETURN PROC CPUINFO DOWNLOAD

The operations on the directory itself are defined in the proc_fd_operations data structure (they're boilerplate except for the function that enumerates the entries, proc_readfd, which enumerates the process's open files) while operations on the entries are in `proc_fd_inode_operations.Īnother important area of /proc is /proc/sys, which is a direct interface to sysctl.

cwd is a symbolic link (a slightly magical one), declared by proc_cwd_link, which looks up the process's current directory and returns it as the link content.

Therefore the proc_clear_refs_operations structures defines a clear_refs_write function but no read function.

clear_refs, unlike the entries we've seen so far, is writable but not readable.

It locates te data in the process and prints it out.

cmdline is generated by proc_pid_cmdline in the same file.

Let's look at a few examples of how these entries are generated: These entries are registered in fs/proc/base.c, in the tgid_base_stuff array some functions registered here are defined in other files. You can see the data being assembled on the fly from data in various variables in the kernel, including a few numbers computed on the fly such as the CPU frequency.Ī big part of /proc is the per-process information in /proc/. There the main function is show_cpuinfo, which prints out the desired file content the rest of the infrastructure is there to feed the data to the reading process at the speed it requests it. Taking x86 as an example, we're led to arch/x86/kernel/cpu/proc.c. There is merely a seq_operations structure, and the real meat is in the cpuinfo_op data structure, which is architecture-dependent, usually defined in arch//kernel/setup.c (or sometimes a different file).

BASH RETURN PROC CPUINFO CODE

You can see that the code is pretty much boilerplate code: since most files under /proc just dump some text data, there are helper functions to do that. Taking /proc/cpuinfo as an example, a search for "cpuinfo" leads you to the call to proc_create("cpuinfo, …") in fs/proc/cpuinfo.c.

Kernel versions up to 3.9 provide the functions create_proc_entry and some wrappers (especially create_proc_read_entry), and kernel versions 3.10 and above provide instead only proc_create and proc_create_data (and a few more).

BASH RETURN PROC CPUINFO DRIVERS

Drivers call functions declared in include/linux/proc_fs.h.

BASH RETURN PROC CPUINFO DRIVER

Any driver can register entries in /proc (though as indicated above this is now deprecated in favor of /sys), so if you don't find what you're looking for in fs/proc, look everywhere else. The core handling of /proc entries is in the fs/proc directory. (There are many variants of LXR the one running on is the nicest by far but unfortunately the site is often down.) A little knowledge of C is required, but you don't need to be a programmer to track down a mysterious value.

BASH RETURN PROC CPUINFO DOWNLOAD

You can download the source on your machine, but this is a huge program, and LXR, the Linux cross-reference, is a big help. Your third entry point, when the documentation doesn't cover it, is reading the source. The /proc filesystem in the kernel documentation.Your first and second entry points for documentation about /proc on Linux are: Entries like /proc/bus and /proc/fs/ext4 remain where they are for backward compatibility, but newer similar interfaces are created under /sys. In the past, Linux's /proc acquired various files that provide information about drivers, but this use is now deprecated in favor of /sys, and /proc now evolves slowly. Linux extends the proc filesystem with many more entries that report the state of the system, including your example /proc/cpuinfo. Most procfs implementations have a file or directory called /proc/123 to report information about the process with PID 123.

It started its life in AT&T's Bell Labs in UNIX 8th edition as a way to report information about processes (and ps is often a pretty-printer for information read through /proc). Procfs is present in most non-BSD unices. Unlike usual filesystems, the filesystem which is mounted on /proc, which is called procfs, doesn't load data from a disk or other storage media (like FAT, ext2, zfs, …) or over the network (like NFS, Samba, …) and doesn't call user code (unlike FUSE). The fact that the content is generated on the fly explains why almost all files have their time reported as now and their size reported as 0 - here you should read 0 as “don't know”. Whenever you read a file under /proc, this invokes some code in the kernel which computes the text to read as the file content.