Driver - theoretical questions
 

Page http://www.armadeus.com/wiki/index.p...river#Examples refers to few statements that are
strange to me. For example it states that GPIO driver is usable through its /proc interface:

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 ?

Thanks

/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


To query about device descriptors use /dev.
To query a process and its appurtenances use /proc.

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.

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 ;)

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.

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.

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.

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.