Randall R Schulz wrote: > On Monday 28 January 2008 09:59, Bill Anderson wrote: >> ... >> >> I prefer the term pseudo filesystem, since /proc does not reside in >> memory. As with any file system, procfs implements the functions >> defined by vfs, the virtual filesystem. The functions implemented >> actually read from, and in some cases write to, kernel data >> structures. The pathnames under /proc define which functions to call. >> There are a large number of such file systems: rootfs, sysfs, >> relayfs, tmpfs, and the list goes on. It works, because every >> filesystem is an implementation of vfs. > > Where they do _not_ reside is on mass storage. It most certainly _does_ > reside in primary storage (a.k.a. "memory," a.k.a. RAM). The fact that > the information is derived on-demand from the current state of the > system is only incidental and not fundamentally different from the > constituents of any more ordinary file system. > > >> Bill Anderson >> WW7BA > > > Randall Schulz You will not find a structure in the kernel that is an exact reflection of /proc. As I said, it is only a filesystem in that every filesystem is an implemention of vfs. The system calls involving any filesystem, flow through vfs. Furthermore, any module can create an entry in the /proc filesystem, and provide the routines to handle the open, close, read, and write requests. The reason for the existence of /proc is to provide a link between kernel space and user space that does not involving the creation of a system call to handle every request for information. Furthermore, you can configure the kernel so that it does not create a /proc structure. Of course, some of the user space commands will not work (eg: ps, vmstat, lsof, lsmod, lsusb, lspci, and others), as they derive their information from /proc. If you have an doubts, you can see the source fo information by using strace on any command.
Bill Anderson WW7BA -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
