Could inxi add memory detection？

[GoogleCodeExporter]

Inxi is an awesome tool,but I can't find information（such as production， 
model， volume）about memory，could inxi add this feature？

Original issue reported on code.google.com by leafonsw...@gmail.com on 28 May 2013 at 7:06

[GoogleCodeExporter]

I've noted both on irc and on the forums that the next major release will have 
ram feature, but it's a very difficult one to implement and experience has 
shown me that such features usually take about 2 to 4 weeks to get stable 
depending on the range of user data sets, and the quality of the data, which in 
this case is very low, which means lots of filtering.

I had hoped for some time that /sys would grow to contain ram data, I actually 
do not understand why it doesn't, but it hasn't done so at this point, so I'm 
giving up on that idea and going back to the fallback of using dmidecode to 
grab that data, which has several major negatives, one being that you must be 
root to run dmidecode, the other being that parsing /sys is VERY fast, and much 
more reliable.

But since ram is not appearing in /sys, at least not last I checked, with one 
exception eec ram types, which are almost useless for most users, I decided a 
while ago to just use dmidecode, which also has the advantage of giving 
automatic bsd support as well without further hacks.

I have a crude outline of what -R or -M,  probably -M for memory, will show, 
it's a lot of data, it will show the number of memory bank arrays, usually one 
or two for consumer systems, much more for servers, and I've still not seen an 
actual server dmidecode output which I will need to see before planning this, 
the amount of ram that each bank or array supports, per slot maxes, then the 
population of the arrays, etc. The amount of information available to the 
system is very finite however, sometimes there is no product name, no speed, 
etc, but the capacities are generally present.

The more of these data sets: inxi -xx@14

I can get, that's the full data dump for the system, run as root, with 
dmidecode installed, the better. Particularly from servers with far more ram 
installed than normal, I need to build in that support from the ground up or it 
will be too hard to modify smaller systems to support larger ones.

I don't have 2 to 4 free weeks at the moment nor do I expect to have that for a 
while, but I can collect data in the meantime, usually the more data I have the 
better, but most of inxi's datasets are generated without dmidecode installed 
and not as root, so I have very few dmidecode datasets, I need at least 10 from 
systems of varying age, from old redhats to bsds to real servers with tons of 
ram to normal systems to laptops etc. Experience has shown me with linux/bsd 
features that expecting consistency of any type in output is a major error, so 
I expect inconsistency now, and try to build in support for that from the 
ground up.

That's why I added the recent -w/-W weather option instead, that was a fairly 
quick and easy hack that only took a few days of coding and debugging to get 
stable, now stable in 1.9.7 for the time being.

memory support will be in either 1.10 or 2.0, depending on the version 
numbering selected, probably 1.10 to avoid the now disgustingly popular version 
number inflations made popular by firefox and google chrome browser.

It's alwasy important, of course, to grasp that inxi won't add this feature, I 
will, and that takes a lot of work and time. I used to make the mistake of 
thinking new features would be easy (-R raid and -s sensors come to mind as 
some of my more radically wrong guesses in terms of how long it would take to 
get them stable, and how many user data sets would be required to actually get 
the programming to handle most cases out there that exist), but I have learned 
my lesson, difficult features are not easy and always cost me roughly one month 
of time as a dev, between data collection, analysis, programming, debugging, 
rewriting, debugging, data collection, analysis, etc...

So yes it's the next major feature planned, but don't hold your breath for the 
release day, it will come when it comes.

Original comment by inxi-...@techpatterns.com on 28 May 2013 at 7:14

• Changed state: Accepted
• Added labels: Milestone-Release1.0
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Expecting.......

Original comment by leafonsw...@gmail.com on 29 May 2013 at 5:48

[GoogleCodeExporter]

Issue 49 has been merged into this issue.

Original comment by inxi-...@techpatterns.com on 10 Jan 2014 at 6:02

[GoogleCodeExporter]

Issue 54 has been merged into this issue.

Original comment by inxi-...@techpatterns.com on 29 Mar 2014 at 5:53

[GoogleCodeExporter]

By the way, I lied, ram/memory support will be in a future release, not 2.0, 
since inxi is now at 2.1.x (2.0 was systemd/upstart/ etc support), 2.1 was, 
ongoing, line wrapping dynamically.

So ram is down the road, I keep holding out for /sys ram data, it will be there 
one day, like motherboard stuff was.

Original comment by inxi-...@techpatterns.com on 29 Mar 2014 at 10:42

[GoogleCodeExporter]

Original comment by inxi-...@techpatterns.com on 5 Apr 2014 at 7:13

• Added labels: Type-Enhancement
• Removed labels: Milestone-Release1.0

[GoogleCodeExporter]

Original comment by inxi-...@techpatterns.com on 5 Apr 2014 at 7:13

[GoogleCodeExporter]

Original comment by inxi-...@techpatterns.com on 5 Apr 2014 at 7:14

• Added labels: Priority-Low

[GoogleCodeExporter]

I've laid the crude groundwork for -m Memory in the current trunk, but the 
actual functions are not created, but this feature may come within 2 months or 
so.

I don't see any other things except bug fixes, 2.1.x is stable now give or 
take, the wrapping of lines is largely done, the init system feature of 2.0 is 
stable, most other bugs have been fixed as found or reported.

I've been looking at the dmidecode output to get a better sense of what can and 
can't be done, I'm going to use type 16 and 17, 16 identifies the memory array, 
and 17 is the slot. I wish I could use 5/6 because they have more information, 
but that is not consistently present across systems and it's actually hard to 
know how to match up the 5/6 stuff with the 16/17 stuff without pure guesswork 
on inxi's part, but I may just add those guesses as -xx type data anyway, which 
can be missing or present, I'll see how that goes, but the first version will 
probably use 16/17 types, because those seem to always be present in all my 
dmidecode output samples.

Again, nothing functional will appear for a while, quite a while possibly, but 
the framework for testing/debugging has been added to trunk/inxi so I can keep 
that going with bug fixes while testing memory in branches/one/inxi

Original comment by inxi-...@techpatterns.com on 14 Apr 2014 at 9:07

• Changed state: Started

[GoogleCodeExporter]

Look for -m in 2.2 release, whenever that comes. I don't see any other real new 
features that might come first, so 2.2 will probably be it.

Original comment by inxi-...@techpatterns.com on 14 Apr 2014 at 9:09

[GoogleCodeExporter]

inxi 2.1.90 now has initial memory handling. inxi -m

I have not completed this feature, but its basically working. Still to come are 
-x, -xx, and -xxx extra data, and some other stuff, but the basic stuff most 
people need is now live.

I will wait for feedback on this thread before closing this issue since this 
only went live in stable inxi today.

Original comment by inxi-...@techpatterns.com on 12 Aug 2014 at 5:32

[GoogleCodeExporter]

Closing this issue, for all actual issues with ram/memory data, start a new 
issue report. 2.1.96 is close enough to final where it can be considered to 
close this issue.

Original comment by inxi-...@techpatterns.com on 15 Aug 2014 at 4:45

• Changed state: Fixed