Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
1.use /proc/drivers/gpio/portXmode to ...
2.use /proc/drivers/gpio/portXdir to ...
3.then use /proc/drivers/gpio/portX to ...
...
There is example on using it with shell script as well as from C language. And also (link on the same page)
there is example on using GPIO driver via /dev/gpio/.. nodes.
What I want to ask is why exactly "proc" branches, named like above, and not more or less of them ?
Probably driver somehow dictates it - no matter, I would appreciate some usefull links.
Also why two interfaces - via "proc" and via "dev" and when should I use one or the other ? Could it be
something other then "proc" file system ?
What I want to ask is why exactly "proc" branches, named like above, and not more or less of them ?Probably driver somehow dictates it - no matter, I would appreciate some usefull links.
/proc is a temporary folder containing an internal file system that enumerates processes and all devices related to the process. Thus a device caught into the process is listed how the system sees it, not how the factory describes it.
The best link to learn about /proc is from your terminal, type
Code:
~~$ man proc
Quote:
Also why two interfaces - via "proc" and via "dev" and when should I use one or the other ?
To query about device descriptors use /dev.
To query a process and its appurtenances use /proc.
Quote:
Could it be something other then "proc" file system ?
Yes there are two one more you need to know: /sys and /var
These are basic concepts flowing out of Unix Philosophy. So it is suggested to read the basics about Unix/Linux system. Here is a nice book.
Hope that helps.
Last edited by malekmustaq; 03-09-2013 at 11:26 PM.
Thanks malekmustaq, some of points you emphasized, I red about (maybe not enough). Yet, I still don't know where those names (portXmode, portXdir, ... - X is A,B,C,... ports) came from. For example why not prtXmd or prtXd ...?
Then also, why not only /dev/gpio node, but /dev/gpio/PD31, /dev/gpio/PF14 ... (ie why subnodes and why exactly those names). And userland apps use both - proc and dev (link I quoted).
Probably coming from driver (which I am not familiar with). Unfortunatelly I supose I should also read some driver books.
Maybe I am wrong - but at first glance, didn't notice "/sys" file info in book you mentioned. Sorry if I was wrong, but neither manual pages have related info (although it is less priority to me at the moment).
Thanks
And sorry, I never paid attention to "Yes", you mentioned in your post
Yet, I still don't know where those names (portXmode, portXdir, ... - X is A,B,C,... ports) came from. For example why not prtXmd or prtXd ...?
Then also, why not only /dev/gpio node, but /dev/gpio/PD31, /dev/gpio/PF14 ... (ie why subnodes and why exactly those names). And userland apps use both - proc and dev (link I quoted).
The system has to use the one it sees most fitting to the device it discovers; it merely chooses from among thousands of driver codes ported into the kernel branches. The varying node 'semantic' are given by these codes and is written into the root directory /dev or /proc including distinct information about the hardware such as serial numbers.
Quote:
Probably coming from driver (which I am not familiar with). Unfortunatelly I supose I should also read some driver books.
Your inquisitive attitude is admirable, you are free to read more about it of course. But I think there are more important challenges which need priority, unless maybe if you are on to driver coding.
Good luck.
Last edited by malekmustaq; 03-15-2013 at 10:04 AM.
Actually, /proc is not "a temporary folder." It is an imaginary one. The entire "file" and "directory" structure that you see there has no actual, physical existence. When you "list a directory," "read a file," or "write to a file" (if authorized), you are actually communicating with a kernel API. Drivers can create these and often do. When you access their "files" and "directories," you are conversing with the driver directly.
Thanks malekmustaq, some of points you emphasized, I red about (maybe not enough). Yet, I still don't know where those names (portXmode, portXdir, ... - X is A,B,C,... ports) came from. For example why not prtXmd or prtXd ...?
Then also, why not only /dev/gpio node, but /dev/gpio/PD31, /dev/gpio/PF14 ... (ie why subnodes and why exactly those names). And userland apps use both - proc and dev (link I quoted).
Probably coming from driver (which I am not familiar with). Unfortunatelly I supose I should also read some driver books.
Maybe I am wrong - but at first glance, didn't notice "/sys" file info in book you mentioned. Sorry if I was wrong, but neither manual pages have related info (although it is less priority to me at the moment).
Thanks
And sorry, I never paid attention to "Yes", you mentioned in your post
There are oddnesses all over.
/proc was originally a virtual filesystem - presenting the process table as a filesystem. It turned out to be so useful that people working on the system added other things - like the partition table, cpu information, ... And it got out of hand.
A long time ago, IRIX put the device table in a /sys virtual filesystem, and gradually went to putting most of the devices identified into a /dev as symbolic links to to the /sys tables.
This got people thinking about other tables, and how to manage them - thus the /sys and/or the /proc/sys and the ability to tune the kernel parameters...
This in turn made it easier to do things that formerly required an ioctl definition... So creating such things became even more regulated - and flexible. Now, device drivers register things they want to allow to be tuned into one or the other virtual filesystems.
The names USED for these parameters are selected by device driver author. In some cases, they try to follow some conventions.
The difference between the /dev and the /proc entries is what they are used for. The /dev entries are used by applications to pass data from user space to the driver to the device. Then entries in the /proc filesystem are used to control how the driver works (things like buffer sizes, sampling rates, ...)- not the data passing through the driver.
You can get a fair amount of information from the "man proc" page - though it may be a bit out of date with respect to a specific kernel, it should give you an idea of what it is.
You can google for "procfs" "sysfs" and "devfs", which should find you documentation on each of these virtual filesystems. Internally, they all work the same way, but have different areas of the kernel to work with.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.