ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
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.
I am using Linux 5.15.84 running on Raspberry Pi 4B and trying to use the function open() to open /dev/mem. But got the error because of permission denied.
crw-r----- 1 root kmem 1, 1 Jan 17 21:44 /dev/mem
As /dev/mem is owned by root, is giving root permission temporarily the only way out?
At the same time, in another program, I am able to open a file in /proc. That file is also owned by root.
-rw-rw-rw- 1 root root 0 Jan 23 22:19 /proc/driver-gpio
What is the difference when use open() to open these two files?
Thank you Pan64 for raising this question. I am looking to write a user space driver and find an example which use this way to access to GPIO registers. Just want to test this method to write an user space driver.
It looks it is not a decent way to write a user space driver. Any suggestions?
Something else to realize is that /dev, /proc, /sys are non-existent "filesystems."
Each of these are, in fact, "Linux kernel APIs." There is absolutely nothing "physically real" about them.
And so, even though the metaphor of "directories, device-nodes and files," with associated "permission masks" and "content," has generally been retained, there might be exceptions to the rule. It is entirely up to the kernel itself. Fundamentally, they are all APIs.
Last edited by sundialsvcs; 01-28-2023 at 09:42 PM.
Something else to realize is that /dev, /proc, /sys are non-existent "filesystems."
Each of these are, in fact, "Linux kernel APIs." There is absolutely nothing "physically real" about them.
And so, even though the metaphor of "directories, device-nodes and files," with associated "permission masks" and "content," has generally been retained, there might be exceptions to the rule. It is entirely up to the kernel itself. Fundamentally, they are all APIs.
Thank you sundialsvcs!
One thing to clarify. When you say "up to the kernel itself", what does this mean? Does it mean its accessibility is up to kernel, not anything like normal file?
One thing to clarify. When you say "up to the kernel itself", what does this mean? Does it mean its accessibility is up to kernel, not anything like normal file?
Those are sometimes called virtual filesystems, they look like a filesystem. When you try to access them (like /dev/mem or /proc/<whatever> the kernel will recognize it, do something and actually will simulate a filesystem-like behavior.
(for example cat /proc/<PID>/cmdline will display the command - how the process <PID> was started, but that file actually does not exist at all).
One thing to clarify. When you say "up to the kernel itself", what does this mean? Does it mean its accessibility is up to kernel, not anything like normal file?
What I literally mean is that: "this is a kernel API" (API = Application Program Interface) which merely presents itself as "files and directories." (Part of this implementation is to provide "ownership and permission-masks.") But, at the end of the day, everything that you "think you see," and everything that you can "do," is determined and implemented solely by the kernel itself.
Yes: "it is not anything like 'a normal file,' yet it perfectly appears to be."
You "ask to open, read or write a 'file' in some 'directory.'" The kernel interprets your request, decides if you can do it (and if so, just what you should see ...), and if so presents the results to you "as a 'file.'" But it is "100% an illusion." There is no physical file, and there is no directory.
"/dev, /proc, /sys ..." they don't exist. (Well, some entries in "/dev" do correspond to physical devices, but some don't.)
Personally, I think that this is a brilliant approach because, "in Unix/Linux, 'everything is a file.'" Kernel API's are often very difficult to deal with, but this one is ... elegant.
Last edited by sundialsvcs; 02-02-2023 at 12:54 PM.
Personally, I think that this is a brilliant approach because, "in Unix/Linux, 'everything is a file.'" Kernel API's are often very difficult to deal with, but this one is ... elegant.
It is indeed brilliant and elegant! For comparison look at [put anything else here].
Thanks Chris, pan64, sundialsvcs, astrogeek, dugan for your reply and sharing the link.
I found this article that explains the details of /dev and /proc. https://www.linux.com/news/using-dev...-file-systems/
It looks they are the ways to interact with the Linux kernel, not serving the purpose of access to the devices.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.