Project

General

Profile

Actions

action #5638

closed

worker: don't use lscpu

Added by lnussel over 9 years ago. Updated 13 days ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2014-12-22
Due date:
% Done:

0%

Estimated time:

Description

the worker shouldn't call external commands like lscpu. Not sure what we need the cpu model name and op-mode for but the main information, the architecute is already available in $machine, provided by an earlier uname() call.
If this extra information is really needed /proc/cpuinfo can be read.

Also, get_capabilities doesn't need to be called over and over again as cpu and memory usually don't change.

Actions #1

Updated by coolo over 9 years ago

what's wrong with extenal programs? I agree not having to call it more than once, but what's wrong with once?

Actions #2

Updated by lnussel over 9 years ago

coolo wrote:

what's wrong with extenal programs? I agree not having to call it more than once, but what's wrong with once?

Same information is available via uname syscall resp /proc/cpuinfo. no need to parse output of programs that use exactly the same source of information.

Actions #3

Updated by coolo over 9 years ago

but now that it's done - what's the benefit of rewriting it?

Actions #4

Updated by k0da over 9 years ago

lnussel wrote:

coolo wrote:

what's wrong with extenal programs? I agree not having to call it more than once, but what's wrong with once?

Same information is available via uname syscall resp /proc/cpuinfo. no need to parse output of programs that use exactly the same source of information.
Then we have to deal with inconsistency in cpuinfo across architectures. IMO lscpu provides more unified output.

Actions #5

Updated by coolo over 8 years ago

  • Status changed from New to Rejected

I still don't see the benefit of changing it

Actions

Also available in: Atom PDF