On Thu, Nov 02, 2017 at 05:54:08PM +0100, Gerald Schaefer wrote:
> Sorry for the late answer. I'm not sure if I understand the problem, it
> "works as designed" that the range merging is done based on the output
> columns, but I see that it was not really described as such. So I do
> like the note that you added with the above mentioned commit.
>
> However, regarding the --split option, I think it may be confusing at
> least for human users, if an "lsmem -oRANGE" will now print more than
> one range, even if this is now based on a "fixed" set of default columns
> that are used for merging (but "subject to change" according to the man
> page).
OK, I think we can support both concepts :-) I have modified lsmem to:
- follow output columns for split policy by default (= your original implementation)
- the --split is optional and may be used to override the default behavior
it means for humans it's probably less concussing and advanced users may
define by --split another way how to generate the ranges.
I think it's good compromise and it's backwardly compatible with
the previous version. OK?
If yes, I need to backport this change to RHEL7.5 :-)
> I also do not really see the benefit for script usage, at least if we
> define it as "expected behavior" to have the ranges merged based on the
We want to keep it user friendly. The "expected behavior" (now
default) forces you to parse lsmem output to filter out unnecessary
columns (if you care about RANGE only).
And in all our utils the --output option really control the output, but
no another behavior.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
