context.memTotalPhysicalBytes(): Use a Syscall

[alrs]

This looks to be either:

1. Me not understanding a corner case that requires getting memory information out of logfiles.

2. A good place to use syscall.

If you're open to using system calls instead of parsing files, there are probably a few more commits like this in me.

[alrs]

Thinking about this, it's more likely you're looking for something like this, right?

https://github.com/digitalocean/go-smbios/blob/master/cmd/lsdimms/main.go

[jaypipes]

Thinking about this, it's more likely you're looking for something like this, right?

https://github.com/digitalocean/go-smbios/blob/master/cmd/lsdimms/main.go

Interesting code there, thanks for linking it here! I think the above may be a good approach for adding the Linux implementation of @KingRial's Windows-specific patch that adds memory-module/DIMM information: #162

Thoughts?

[jaypipes]

Unfortunately, this won't return the physical amount of memory :) See explanation inline...

[jaypipes]

actually, sysinfo_t.totalram is the usable memory amount, not the physical memory amount :)

http://man7.org/linux/man-pages/man2/sysinfo.2.html

The results of sysinfo(2) are replicated in /proc/meminfo, which is what is used to get the total usable bytes below. See the comment on (original) line 124 below that explains why we look up the physical memory size using syslog.

That said, I think using the DMI approach (that the digitalocean library uses) would allow us to simply add up the physical size of all DIMMs attached to the host. The only problem with that is, of course, DMI access is a privileged operation so we're back in the same situation as before that caused me to originally write this code... (accessing syslog sometimes requires lower privileges than accessing DMI information, thus the fallback to using syslog instead of DMI)

See the note