Quote:
Originally Posted by zeeshanharis
what is the actual difference between /sys and /proc directories?
|
Roughly, proc exposes process information and general kernel data structures to userland. sys exposes kernel data structures that describe hardware (but also filesystems, SELinux, modules etc). I don't have the impression that the distinction is very sharp, and there is definitely some overlap.
Quote:
|
And the fact that /proc also has running process info stored and sys has the whole system and kernel info stored what is meant by that?
|
It's not clear to me what you want to know.
Quote:
|
How does /proc identify the hardware such that it displays its vendor and other stuff, are there any rules through which it decides this info?
|
It's sys rather than proc that displays hardware. What happens is that the PCI bus (or whatever other bus is used; PCI in most situations) discovers hardware at boot time and when it is added on the fly, and the PCI bus drivers get that information. The rules are based on the PCI standard. After discovery, we have kernel data structures that describe the hardware, and /sys exposes them to you and me.
Quote:
|
Why /sys has only one value per file for all the device attributes?
|
Code:
# cat /sys/block/dm-2/stat
143 0 2428 208 10 0 4121 333 0 526 541
But it is true, most regular files under /sys represent a single device attribute or a specific action that you can trigger by writing to the file. I would think it makes it easier to manage device properties this way, but I am speculating. To me, it makes a lot of sense.
Quote:
|
which of these is Udev dependent on?
|
Definitely /sys, probably also /proc.
Quote:
|
How often Linux checks for hardware errors and where does that happen? Machine check errors, where are they stored?
|
I don't think that there is a single answer. Each subsystem or driver has its own way to check for errors, or doesn't check at all. Where are errors stored? In the data structures that describe hardware, I would say.
