Lomanic

> But if we use Open Hardware Monitor to implement it, all user or application should include this DLL, does it increase the complexity of application deployment? Not necessarily if...

As I see it, packr converts an asset to a .go source code file with the asset's contents serialized to a `[]byte` variable. We could commit this (probably huge) file...

Indeed this function is only implemented for linux. Implementing this is platform-dependent. For darwin, we could shell out to `system_profiler -detailLevel basic SPSerialATADataType` (parse its xml with `-xml` flag). For...

Sure it would be a logical step compared to what OS statistics gopsutil is already able to return, but I think we already have a large API and few contributors...

Implementing new battery-related functions (in `host` package probably, like the SensorsTemperatures functions), while offloading implementation to `distatus/battery`, is doable indeed.

https://github.com/shirou/gopsutil/pull/541#issuecomment-401195949 on how to do that https://github.com/shirou/gopsutil/issues/435 was auto-closed by #541 being merged, but this PR was then reverted and the issue not reopened.

That looks a great info to retrieve as in this case `VendorID`, `Family` and `ModelName` are empty, but information isn't standardized, on my phone this field is set to `Qualcomm...

Thanks for these samples, could you please edit your message so it's easier to see where they begin/end? Was confused for a moment as I was seeing numerous Hardware fields...

Oops, it was my mobile client (Octodroid) that didn't visually separate the different sections. Thanks in advance if you submit a PR.

I worked on this issue in the following branch https://github.com/Lomanic/gopsutil/tree/issue881 (WIP, will have to rewrite history). If you check [`cpu_test_linux.go`](https://github.com/Lomanic/gopsutil/blob/issue881/cpu/cpu_linux_test.go) in the mocked CPUInfo test, you will see how it...