SUSE Revives Patches For Exposing /proc/cpuinfo Data Over Sysfs

[phoronix]

Phoronix: SUSE Revives Patches For Exposing /proc/cpuinfo Data Over Sysfs

Back in 2017 were patches for exposing /proc/cpuinfo data via sysfs for more easily parsing selected bits of information from the CPU information output. That work never made it into the mainline kernel but now SUSE's Thomas Renninger is taking over and trying to get revised patches into the kernel...

http://www.phoronix.com/scan.php?page=news_item&px=SUSE-Revives-CPUInfo-Sysfs

[knweiss]

After spending some time parsing /proc and /sys files for various projects I wonder if it wouldn't be advantageous if the kernel would export this information in a text format that's parsable with a "standard" parser (toml, yaml, json, whatever) and at the same time remains human-readable.

The major drawback I can see is that parsing these formats from shell scripts requires additional tools.

[Guest]

After spending some time parsing /proc and /sys files for various projects I wonder if it wouldn't be advantageous if the kernel would export this information in a text format that's parsable with a "standard" parser (toml, yaml, json, whatever) and at the same time remains human-readable.

The major drawback I can see is that parsing these formats from shell scripts requires additional tools.

jq exists, so I don't really see a reason why you wouldn't want to use JSON for this sort of thing. Pretty print it so every property is on a separate line, and even grep would suffice for basic filtering of output if you don't want to use jq for whatever reason.

[Britoid]

I guess this makes a lot more sense than having /proc/cpuinfo

[Danny3]

I wish this output would be simple and logical for a human to understand like:
1. Name of the processor
2. Number of physical processors (sockets)
3. Number of each processor cores
4. Number of each processor threads
5. Processor memory sizes
6. Extensions
7. Base clock and boost clock

I think that Windows 8/10 task manager has a very logical and easy to understand information about the processor and could be a very good example for how to display processor information.

[pal666]

The major drawback I can see is that parsing these formats from shell scripts requires additional tools.

the whole point of file per value is that the only tool you need in shell script is var=$(<filename)

[pal666]

I think that Windows 8/10 task manager has a very logical and easy to understand information about the processor and could be a very good example for how to display processor information.

task manager is gui, rather than kernel api. you can write any gui for presenting subj, maybe someone already written one

[starshipeleven]

I wish this output would be simple and logical for a human to understand like:

This is not a human interface. It is an API, an interface for software.

[Danny3]

This is not a human interface. It is an API, an interface for software.

Well, it wouldn't hurt to make the API human readable, you can have both if you want to.
But I think we'll have to wait again for systemd developers to pick it up and diplay it in a nicely formatted text.

[Danny3]

task manager is gui, rather than kernel api. you can write any gui for presenting subj, maybe someone already written one

I was thinking that it should be similar to the output of: /proc/info
Which looks like garbage in my opinion with so much unordered, unindented information.
Looking at it I cannot figure out how many physical processors are on the motherboard, how many cores, how many threads.
Kernel API or not, why it should be so ugly ?
Why can't they use a format like JSON with a nested structure which you can simply pretty print and be easily understandable also by a human ?