Talk:procfs

Latest comment: 8 years ago by Olivier Mengué in topic GNU ps?

Procfs does not merely display information, but it can be used to implement kernel options (ie. ACPI) by for example using echo to change a proc value. However I am unclear on how the kernel treats procfs, does it read from the "file" constantly? John Riemann Soong 04:17, 25 July 2006 (UTC)Reply

Procfs does not contain "real" files, it is a virtual filesystem that communicates with the kernel. Techefnet 00:16, 8 November 2006 (UTC)Reply
It is a pseudo-filesystem (in the developers terms), which translates filesystem changes into kernel configuration options (such as the ip_forward option), and kernel information is exposed as files in the subdirectories of /proc/. In real terms it is not separate from the kernel to the extent that the kernel would need to read it constantly, it is a translation layer which resides entirely in the kernel itself, and because all filesystem changes or reads must go through the kernel anyway they are translated at this point into various options instead of altering the files (Which don't really exist). When you read the /proc filesystem with commands such as "ls" or "cat" you are effectively asking the kernel for this information directly. Mrsteveman1 06:02, 3 August 2007 (UTC)Reply

The linux section is written somewhat like a tutorial, there is one line which is specifically written as if the writer is speaking to the reader, i think it says something like 'the one i have used the most', just seems a little un-wikipedia like for lack of a better term. It would be better to simply list a few (not all) of the various /proc interfaces, perhaps the most significant such as cpuinfo and meminfo, a few options that can literally change kernel behavior, and things such as the process, module, and partition lists. Everthing else is a bit excessive considering the relative lack of similar info given for other operating systems. Mrsteveman1 06:02, 3 August 2007 (UTC)Reply

pseudo-file

edit

pseudo-file as in device node/device file? --Abdull 11:08, 30 August 2007 (UTC)Reply

No, at least not as described by those articles - these files appear as regular files, except that their size is usually shown as 0. Once one reads from them, their content is displayed by the kernel. --Joy [shallot] 00:06, 31 August 2007 (UTC)Reply

Refreshs

edit

How often are statistics in /proc updated? The article doesn't say. --Gwern (contribs) 02:18 11 December 2007 (GMT)

They are calculated when you read the pseudo-files: remember, they aren't traditional files, they don't occupy space on a filesystem. -- anon —Preceding unsigned comment added by 128.240.229.68 (talk) 12:51, 19 February 2008 (UTC)Reply

/proc/cpuinfo table seems to think that Intel/x86 is the only ISA in the world

edit

It should at least mention what Linux does on other processors than Intel x86 ones, or, possibly, that this only is implemented on Intel x86.

"ps operates entirely in user mode"?

edit

The remark "For example the GNU version of ps operates entirely in user mode, using the procfs to obtain its data" does not make much sense to me. One has to make kernel calls to read procfs. I do not see how that is different from doing other kernel calls to obtain process information.

ps uses the file system so why ps shoud need kernel calls?--Thaodan (talk) 15:44, 29 November 2012 (UTC)Reply
You still need to call the kernel to open, read, and close files. But they are generic calls, and it looks like the article now just says ps doesn’t use any specialised calls. Vadmium (talk, contribs) 22:12, 29 November 2012 (UTC).Reply

/proc/cpuinfo and /proc/memstat does not belong to this page

edit

I deleted them, if more description on the Linux procfs should be giver, I think it would be definitively better to put them in a new article —Preceding unsigned comment added by 208.85.112.101 (talk) 17:48, 5 February 2009 (UTC)Reply

GNU ps?

edit

The "GNU ps" mention should be clarified. The usual implementation of ps on GNU/Linux is from procps which is not a GNU project. If there is really a "ps" implementation in a GNU package (may be in GNU Hurd), that should be explicitely mentioned, but I'm not sure that was the intent of the author of the sentence. Olivier Mengué |  05:56, 31 January 2016 (UTC)Reply