I'd like to learn about proc and sysfs entries.
So far, what I have understood is that, proc entries are the values which is set to proc file system. I'm not sure whether I'm correct. Could anyone explain it in detail about its real need and where it is used? Please provide me links to know it better. Any kind of guidance is accepted.
The /proc filesystem is a special, software-created filesystem that is used by the kernel to export information to the world. Each file under /proc is tied to a kernel function that generates the file's "contents" on the fly when the file is read. We have already seen some of these files in action; /proc/modules, for example, always returns a list of the currently loaded modules.
/proc is heavily used in the Linux system. Many utilities on a modern Linux distribution, such as ps, top, and uptime, get their information from /proc. Some device drivers also export information via /proc, and yours can do so as well. The /proc filesystem is dynamic, so your module can add or remove entries at any time.
Fully featured /proc entries can be complicated beasts; among other things, they can be written to as well as read from. Most of the time, however, /proc entries are readonly files. This section concerns itself with the simple read-only case. Those who are interested in implementing something more complicated can look here for the basics; the kernel source may then be consulted for the full picture.
Before we continue, however, we should mention that adding files under /proc is discouraged. The /proc filesystem is seen by the kernel developers as a bit of an uncontrolled mess that has gone far beyond its original purpose (which was to provide information about the processes running in the system). The recommended way of making information available in new code is via sysfs. As suggested, working with sysfs requires an understanding of the Linux device model, however, and we do not
source - http://tjworld.net/books/ldd3/#UsingTheProcFilesystem
u can look at the ldd3 for more detailes.
it is often used as a tool for debuging the device drivers.
i am a newbie.
good luck.
Related
I'm writing a Linux kernel driver for a device that has quite a bit going on and a bunch of interaction from user-space. In order to debug and troubleshoot these interactions I'm storing them in a data array in the driver and need to export this data to user-space via some sort of file node. It'd be great if I could just export the binary data and let user-space parse it into human-readable text but the requirement from other parties involved is to have this done in-driver so one can just cat the file node from the command line and get something readable.
Currently I'm just using a sysfs node but I'm pretty sure that's the wrong place for that sort of thing and I need to able to write out more than PAGE_SIZE of data. What is the proper filesystem object I should be using for this type of thing? I looked at debugfs but it seems to be for more specific things much like sysfs is.
I think the best way is to use the debugfs as its developed just for debugging purpose and only people with the necessary permission which you can decide will be able to access it.
So go ahead with using debugfs
A kernel module I created is constantly generating information that I would like to store within the kernel and be readable from root. I was thinking of storing the information in some sort of log file with specific permissions, but I read that writing to files within the kernel space code is not good.
What is a good way to store information in the kernel that is fast and accessible by root?
~Thanks
If it's constantly generating new information, I would write it out with printk(). This way it will be seen by dmesg as well be written out to /var/log/kern.log.
Although, this is not for sensitive information, since dmesg could be used by any user.
Depending on the type of information, you can also provide it via /proc or /sys files, netlink, relayfs, /dev ioctl.
I'm currently developing an application which needs a lot of system and process information, some of which is only available through /proc, and I have some general questions about accessing the structures.
The application will be run on Linux (kernel >= 2.6), not on any other Unix-flavored OS. It should have access to any data in /proc, I can't say what is necessary now as the specifications are not clear yet, but the whole /proc directory is relevant to the application.
First of all: Is there a good documentation which covers all the features added / removed from kernel version to kernel version? One thing I'm curious about in particular is the format of the individual files. Can I take that for granted? Does it change among kernel versions?
Hooking up the parsing process based on the kernel wouldn't be a problem at all, it's just that I couldn't find any good docs on what has changed from version to version which could help me catching parsing errors in beforehand.
In addition: Is there a definite list of features that can be activated / deactivated by kernel options (except of course the /proc-feature itself)? I'm looking for a list of files / directories that only exist with the appropriate options being set in the kernel.
As an example of what I'm thinking of, this is a link to the proc manpage (http://linux.die.net/man/5/proc) which includes a lot of good information, e.g. some options include the earliest kernel version they were available at, some include whether a module is necessary to be loaded. This does not describe the output format of all information though, which is something I need if I want to parse it (e.g. if it is consistent throughout all kernel versions or changed at some point).
The second thing I'm wondering about is what happens if the process queried dies while being queried. What is my time interval? For example if I'm going to fetch a list of processes reading all the structures, and parse them one after another, what happens if my process x dies before I get to read it? Even if I check if the directory exists, it could still be gone one application call later.
Last but not least: Is there any major distribution out there that is not mounting proc?
From what I understand, a lot of common tools are based on the /proc interface such as lsmod or free, so I'm guessing that I can expect /proc to exist almost always.
The /proc interfaces are pretty stable (unlike the /sys interfaces), even if nothing is guaranteed. Almost all changes are backwards compatible, at least if they've been around for a few versions. You should
stick to the documented interfaces to be safe. If a file exists, its format may be extended in later versions, but normally in a backwards compatible way, e.g. adding columns to a table. The parts that are most at risk of disappearing are parts concerning hardware susbystems such as ACPI or SCSI, which are migrating to /sys (with a long transition period when both exist).
Most of the information is architecture-independent, except for hardware information (e.g. /proc/cpuinfo has very different fields on different architectures).
The main documentation is Documentation/filesystems/proc.txt in the kernel source. Consider proc(5) to be the overview and proc.txt to be the fine details. The kernel documentation is often incomplete, so don't be surprised if you need to resort to reading the source sometimes.
Most optional parts of /proc are activated by default if the driver whose data it exposes is included in the kernel. The exceptions are mostly related to hardware features that rarely need to be accessed from outside the kernel; if you need to access these features, you're probably already expecting to need to dig deeper. Look through Kconfig files in the kernel source for detailed information.
Process data (or hardware data related to removable hardware or provided by unloadable modules) can disappear under your nose. Most files under /proc can be read atomically, with a single read call with a reasonably-sized buffer; if you perform multiple read calls in sequence, drivers are supposed to guarantee that you get well-formed data. There is no way to guarantee atomicity between reads of separate files; if you're reading information about a process, this process can die at any time, and in principle could even be replaced by another process with the same PID before you're finished.
As it says in the description of /proc, “everyone should say Y here”. All desktop/server Linux systems and most embedded Linux systems must have /proc; a lot of things, including ps and other process management commands, many filesystem and device-related tools, and module loading, require it. The only systems that might be able to dispense with /proc are very small single-purpose embedded systems that support a single hardware configuration and run a fixed set of programs. You can count on its being here.
I'm writing a patch for VFS FAT implmentation on kernel 3.0
I want to add posix attributes to FAT files that are created in linux.
to achive that, I must save a file that contains all the relevant information on the mounted drive.
I know that reading and writing files from kernel space is something normally shouldn't be done, and I'm looking for another way to read/write the data.
I saw articles on the net that suggested to use /proc or to create a userspace daemon that will do the IO for me. I wanted to know if anyone saw or know where can I look at an implmentation of a thing like that,because I didn't find any examples for that over the net.
I'm not looking for a read/write to proc example, I want to see an entire solution for this issue.
Have a look at the quota implementation; this is a mechanism (ok, presumably not available on vfat) which reads/writes files from the kernel.
Additionally, the "loop" block device is another example of a kernel facility which does file IO.
I am more common with the QNX os and I could change the arguments for the ide driver on startup. I wanted to change the arguments that get started in a linux kernel for the jfs filesystem which mounts a flash card. I can't seem to find a good web source for this information but I am sure I am not "googling" it right.
What are the different options available for the jfs/ide driver and where do I change them for the current running driver?
Thank you and I apologize this isn't exactly programming but this site always produces great answers when I ask a programming question so I figure it might help here too.
ok, i finally found out it is defined in the /etc/fstab file. Now I just need to find out what options are available and best for a compact flash card.
Options for most filesystems are shown in the "mount" manpage.
The ata driver may also have various tunables. You can probably change these in real time with "hdparm".
Some options might be filesystem create time options, in which case mkfs will document them.
See the relevant man pages.
If you want to pass options to jfs, you need to pass them as part of kernel boot
line, which is specified in your grub.conf or lilo.conf file. You can find the supported
options in the Documentation/ directory of the kernel source, or the jfs source itself.
As for the recommended mount options, you need to look at the mount(8) man page.
I would recommend noatime,nodirtime at a mininum. The default is atime, which
causes the file inode to be updated everytime you look at a file.