[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb121cc4-8d4e-4daa-af9b-daf531c12db2@intel.com>
Date: Tue, 19 Aug 2025 10:14:36 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Sohil Mehta <sohil.mehta@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org
Cc: Borislav Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Nikolay Borisov <nik.borisov@...e.com>,
Alex Murray <alex.murray@...onical.com>,
Andrew Cooper <andrew.cooper3@...rix.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] scripts/x86: Add a script to update minimum Intel
ucode revisions
On 8/18/25 12:01, Sohil Mehta wrote:
> +parser.add_argument('-u','--ucode_path', required=True,
> + help='Path to the microcode files')
> +parser.add_argument('-o','--output', dest='header', default=ucode_hdr,
> + help='The microcode header file to be updated (default: intel-ucode-defs.h)')
So, thanks for fixing this up and adding the sorting.
But I'm not sure what the point is of making it less flexible and adding
these command-line arguments to it. Before, I would just hand it a path
to a bunch of ucode files, and dump the output somewhere:
foo.py ~/path/* > out.h
I just went and tried to use my version of the script to dump headers
for every microcode release:
git rev-list --all | while read rev; do
git checkout $rev;
python3 dave.py ~/path/* > foo.${rev}.h
done
But with your version, I can't do that. I have to create the header
file, then point the script to it. I also have to consume microcode
files from a single directory.
So, it's less flexible and harder to use with those command-line
arguments. It's obviously not the end of the world, but why add code to
the script for this? Why is it needed?
Powered by blists - more mailing lists