[Devel] [PATCH 2/3] Introduce the res_counter_populate() function
Kir Kolyshkin
kir at openvz.org
Thu Oct 4 05:11:57 PDT 2007
Pavel Emelyanov wrote:
> <...skipped...>
> +static char * units_names[RES_UNITS_MAX][RES_CFT_MAX] = {
> + [RES_UNITS_BYTES] = {
> + "usage_in_bytes",
> + "limit_in_bytes",
> + "failcnt",
> + },
> + [RES_UNITS_ITEMS] = {
> + "usage",
> + "limit",
> + "failcnt",
> + },
> +};
>
Sorry for being late in the game, but can we please bring back the issue
of naming those files?
To me, names like "usage_in_bytes" doesn't really make much sense,
unless we will also have something like "usage_in_pages" next to it --
i.e. use several different units for the same resource. I seriously
doubt we should...
Still, we need a way to denote units of measurement for each resource.
Here are the options I can think of:
0. Hardcode the name of measurement units in file name, as it is
(partially -- only for "bytes" done now). Looks ugly to me, access
interface will be inconsistent, not program-friendly: as file name is
not "usage", but "usage*", it will be easy to implement in shell, but
requires some additional logic in C.
1. One obvious way is to put it in documentation, i.e. say something
like "this parameter is measured in bytes". The problem is documentation
is a bit far away from the actual file we read the value from.
2. Put units into the file itself, i.e. "cat usage" will print something
like "1024 bytes". This is very user-friendly, but not really
program-friendly: while in C it is just fscanf(fd, "%d", &val), shell
users will require something like "cut -d ' ' -f1" to extract the
numeric value.
3. Put units into a separate new files named "units" (or, well,
"measurement_units" (or even "measured_in") if you are fan of long
descriptive names). So, "cat units" will show us "bytes" or "items" or
"pages"...
4. Encode units into a file name, like "measured_in_bytes". This would
be a separate file which exist just for the sake of the name. This looks
bad to be since getting this info from a program is complex.
I prefer approach #3 -- easy and consistent.
> <...skipped...>
>
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list