updated cpu_count - use dmidecode #13

Merged
PeterSurda merged 1 commits from swapnil/idlers-agent:main into main 2024-06-24 02:24:50 +02:00
Owner
No description provided.
PeterSurda added 1 commit 2024-06-24 02:11:05 +02:00
updated cpu_count - use dmedecode
All checks were successful
buildbot/multibuild_parent Build done.
buildbot/travis_bionic Build done.
bd9a848737
Author
Owner

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.

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 02:24:42 +02:00
PeterSurda merged commit bd9a848737 into main 2024-06-24 02:24:50 +02:00
Member

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?

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?
Author
Owner

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
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Sysdeploy/idlers-agent#13
No description provided.