diff mbox series

[v2] tunables: sort tunables list

Message ID xn4j9yumr1.fsf@greed.delorie.com
State New
Headers show
Series [v2] tunables: sort tunables list | expand

Commit Message

DJ Delorie June 12, 2024, 4:52 p.m. UTC
Florian Weimer <fweimer@redhat.com> writes:
> We already require GNU awk and use asorti, so I'd prefer built-in
> sorting here, too.

Ok.

> The other mechanics look right to me.  I remember doing something
> similar, but must have discarded it because of the issue you mentioned
> before (new tunables landing in the middle of the list).

I did a test where I added a new tunable at the end of the last *.list
given to the original script.  It added it third in the final output.
So we *already* have the "new tunables change most of the tunable IDs"
and sorting the list only changes how many IDs change, not whether any
do.

The POSIX spec specifically says that "foo in bar" returns entries in no
particular order, too, so any consistency is coincidental.  Sorting
makes the output explicitly consistent.

[v2: use asorti()]

Comments

Florian Weimer June 12, 2024, 5:48 p.m. UTC | #1
* DJ Delorie:

> Florian Weimer <fweimer@redhat.com> writes:
>> We already require GNU awk and use asorti, so I'd prefer built-in
>> sorting here, too.
>
> Ok.
>
>> The other mechanics look right to me.  I remember doing something
>> similar, but must have discarded it because of the issue you mentioned
>> before (new tunables landing in the middle of the list).
>
> I did a test where I added a new tunable at the end of the last *.list
> given to the original script.  It added it third in the final output.
> So we *already* have the "new tunables change most of the tunable IDs"
> and sorting the list only changes how many IDs change, not whether any
> do.

Yeah, that's why I came up with the @order directives.

What's the commit you plan to use?  It should reference bug 30027.

> diff --git a/scripts/gen-tunables.awk b/scripts/gen-tunables.awk
> index fc3b41376f..d9f326b63b 100644
> --- a/scripts/gen-tunables.awk
> +++ b/scripts/gen-tunables.awk
> @@ -131,6 +131,11 @@ END {
>      exit 1
>    }
>  
> +  # TYPES is an associative array where the index is the data
> +  # TYPESA is an indexed array where the value is the data
> +  # We sort TYPESA
> +  typecount = asorti (types, typesa)

We don't use awk --posix, right?  So this ordering is not
locale-sensitive?

Thanks,
Florian
diff mbox series

Patch

diff --git a/scripts/gen-tunables.awk b/scripts/gen-tunables.awk
index fc3b41376f..d9f326b63b 100644
--- a/scripts/gen-tunables.awk
+++ b/scripts/gen-tunables.awk
@@ -131,6 +131,11 @@  END {
     exit 1
   }
 
+  # TYPES is an associative array where the index is the data
+  # TYPESA is an indexed array where the value is the data
+  # We sort TYPESA
+  typecount = asorti (types, typesa)
+
   print "/* AUTOGENERATED by gen-tunables.awk.  */"
   print "#ifndef _TUNABLES_H_"
   print "# error \"Do not include this file directly.\""
@@ -141,7 +146,8 @@  END {
   # Now, the enum names
   print "\ntypedef enum"
   print "{"
-  for (tnm in types) {
+  for (i = 1; i <= typecount; i++) {
+    tnm = typesa[i];
     split (tnm, indices, SUBSEP);
     t = indices[1];
     n = indices[2];
@@ -157,7 +163,8 @@  END {
   print "# include \"dl-tunable-types.h\""
   # Finally, the tunable list.
   print "static tunable_t tunable_list[] attribute_relro __attribute_used__ = {"
-  for (tnm in types) {
+  for (i = 1; i <= typecount; i++) {
+    tnm = typesa[i];
     split (tnm, indices, SUBSEP);
     t = indices[1];
     n = indices[2];
@@ -172,7 +179,8 @@  END {
   # Map of tunable with environment variables aliases used during parsing.  */
   print "\nstatic const tunable_id_t tunable_env_alias_list[] ="
   printf "{\n"
-  for (tnm in types) {
+  for (i = 1; i <= typecount; i++) {
+    tnm = typesa[i];
     split (tnm, indices, SUBSEP);
     t = indices[1];
     n = indices[2];