Re: [PATCH 4/9] cpuidle: Introduce .abbr (abbrevation) for cpuidle states

[Thomas Renninger]

On Wednesday 12 January 2011 07:56:45 Len Brown wrote:
> I'm not fond of inventing a new 3-character abbreviation field
> for every state because display tools can't handle the existing
> 16-character name field.
I am also not "fond" of it, but it's a sane and easy
solution and appropriate for this issue.
 
> If the display tools can only handle 3 characters,
> then why not have them simply use the 1st 3 characters
> of the existing name field?
You mean use:
C3 NHM
instead of
NHM-C3
for intel_idle?

Then userspace has to parse the two informations glued
together, get rid of the whitespace, etc.
But by sysfs convention a separate file must be used
if two data are passed to userspace which is the case here.

> If that is not unique,
> then re-arrange the strings so that it is unique...
See above, it would unnecessarily make life hard for
userspace.
Afaik sysfs entries do not consume resources as long as
they do not get accessed.

> Of course the ACPI part of this patch will not apply,
> as it depends on patch 1 in this series, which was erroneous.
> For ACPI, the existing name field is already fine,
> as C%d fits into 3 characters.
For acpi_idle only it would work, but this is (nearly) the only
one.
For example for sh arch:
name: SuperH
"SH SuperH" contains two data and should get split up into:
name: SuperH
abbr: SH

By convention the first characters of "description" could be
used, but you would again end up in userspace parsing and
double info in one sysfs file.

I hope that's enough for convincing, I'd really like to go
the .abbr way. Do you give me an acked-by for that one?

Thanks,

    Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/