Re: [Devel] [PATCH 2/3] Introduce the res_counter_populate() function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers

[Index of Archives]     [Cgroups]     [Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux