I had made a similar change in my local tree, but used make's :ts flag instead. I guess the sed expression more portable, though:

There are a bunch of cpython-generated files in the plist that have "37" hardcoded in the filename. Should those use %%PYTHON_VER%% instead?

• newsyslog: re-alphabetize variables

• newsyslog: don't add -f to zstd args in this patch
• newsyslog: remove unneeded braces
• newsyslog: convert args to const char**
• newsyslog: don't strdup pgm_name

• newsyslog: more cleanup
• newsyslog: more extensive cleanup

The rabbit hole goes deeper than I thought. The do_zipwork function came into being with @gad 's rS130167 commit back in 2004. Then the array of compression types was added in rS218127, then compression arguments were added in rS326617. Some of the code from the original commit remained but no longer makes sense, or is now being done in the wrong place.

• newsyslog: calculate the maximum compression suffix length at runtime

Rebase after rS337050 .

Fix typo

I'm open to any other simplification ideas, but the storing of the compression options in their own separate arrays plus that nested loop particularly hurt my eyes.

More updates.

In D15833#335999, @tuexen wrote:

I like the functionality added and that the timeout is configurable via a command line option. However, I would prefer to have the default off... But I leave the decision up to you.

Updated to address comments, and added a -t option to allow for adjustment of the timeout.

In D15833#334839, @bdrewery wrote:

I wonder if the wchan for the process can be printed easily instead of 'sleeping'

In D15833#334836, @mmokhi wrote:

I'd suggest make a new command-line switch for this functionality so we can:
1- set timeout dynamically
2- have the original behavior by not using the switch

In case anyone is wondering why there are fewer files installed as compared to the files extracted from microcode.dat, the old ucode-tool wrote each microcode update into a separate file, whereas the new files combine all the updates for a given family-model-stepping combination into their own files. Multiple updates in the same file will each have a different processor_flags value. Using the iucode-tool program to dump each set of files shows that they both include the same number of updates:

In D4672#244706, @rmacklem wrote:

Dan, does your filesystem use attribute names that start in "system." or "user."?

For what it's worth, this patch seems to work when used with the net/s3ql filesystem. It has a unique method of communicating with the running daemon: it gets/sets extended attributes on a hidden control file in the mounted filesystem.