updated cpu_count - use dmidecode #13

PeterSurda · 2024-06-24T00:11:03Z

PeterSurda commented

2024-06-24 00:11:03 +00:00

No description provided.

PeterSurda added 1 commit 2024-06-24 00:11:05 +00:00

updated cpu_count - use dmedecode

buildbot/multibuild_parent Build done.

Details

buildbot/travis_bionic Build done.

Details

bd9a848737

PeterSurda commented

2024-06-24 00:24:10 +00:00

I think this is a good start. In the next steps, you can think about how to generalise the approach, so you don't have to copy & paste the glue all the time. And also there are cases where multiple matches occur, for example when looking at RAM sticks, there are multiple of them and each probably has a different serial number.

PeterSurda changed title from ~~updated cpu_count - use dmedecode~~ to updated cpu_count - use dmidecode

2024-06-24 00:24:42 +00:00

PeterSurda merged commit bd9a848737 into main

2024-06-24 00:24:50 +00:00

swapnil commented

2024-06-24 03:07:21 +00:00

Hi, what does it mean by "generalise the approach" in this case? Where would we be needing to copy-paste this function? Mutiple matches for "Core Count" and "Thread Count" you mean?

PeterSurda commented

2024-06-24 05:23:36 +00:00

There is way more information to be obtained from dmidecode. The process of opening and parsing the output would need to be repeated, so is better to extract it.

There are multiple approaches possible. One is what you're doing now, getting the whole output first and then pattern matching once per data point. This has the disadvantage that it can't do anything that's not matchable in one line, and doesn't understand which section it is in, in case there are multiple sections.

Another one is to have a stateful parser, i.e. go through line by line while storing the state somewhere (e.g. which is the current section). This has the advantage that it works if you're memory or CPU constrained, it doesn't need to fit the whole output into memory, and each line is only processed once. The disadvantage is that it can result in code that's difficult to understand.

What I would suggest is to split the output into sections (e.g. each section is one value of a list of dict). This can be done by splitting on the '\n\n' string. Then you can detect the DMI type from first line, and each DMI type can have its own parser. This wouldn't work if the available RAM is small compared to the output of dmidecode, but we don't have to worry about that. The code would be easier to understand and change.

There is way more information to be obtained from `dmidecode`. The process of opening and parsing the output would need to be repeated, so is better to extract it. There are multiple approaches possible. One is what you're doing now, getting the whole output first and then pattern matching once per data point. This has the disadvantage that it can't do anything that's not matchable in one line, and doesn't understand which section it is in, in case there are multiple sections. Another one is to have a stateful parser, i.e. go through line by line while storing the state somewhere (e.g. which is the current section). This has the advantage that it works if you're memory or CPU constrained, it doesn't need to fit the whole output into memory, and each line is only processed once. The disadvantage is that it can result in code that's difficult to understand. What I would suggest is to split the output into sections (e.g. each section is one value of a list of dict). This can be done by splitting on the '\n\n' string. Then you can detect the DMI type from first line, and each DMI type can have its own parser. This wouldn't work if the available RAM is small compared to the output of `dmidecode`, but we don't have to worry about that. The code would be easier to understand and change.

Sign in to join this conversation.

No reviewers