Re: [PATCH v2 12/14] platform/x86/intel/ifs: Add current_batch sysfs entry

From: Thiago Macieira
Date: Sun Nov 13 2022 - 16:52:05 EST


On Sunday, 13 November 2022 03:48:40 PST Borislav Petkov wrote:
> > You can't do it with a three-line shell script, but we're not
> > expecting that shell scripts are the means to use this feature in the
> > first place.
>
> I consider it a serious design mistake of having to have a *special*
> tool. A special tool is *always* a burden. You need to build it, supply
> it, make sure it is installable on the target system and so on.
>
> And I'm telling you this with my Linux distributor hat on. It is always
> a pain - trust me.
>
[cut]
> IOW, I really think that designing our interfaces with user friendliness
> in mind should be of much more higher importance. And requiring the user
> to remember or figure out anything she doesn't really need to, in order
> to run the test is a burden.

We agree that it should be operable without a tool. If nothing else, we will
run into situations where we need to debug what's happening and the tool is
not going to work for those conditions. Having a direct access to the API
right there in /sys is great and is one of the things that Linux excels at and
differentiates itself from the competition with.

However, I am saying that we shouldn't have to go out of our way to make the
extreme corner case easy if it comes to the detriment of the 99% case.

Anyway, we can update the tool to print "%02x-%02x-%02x-%02x.%s" instead of
"%d". That's trivial to us. I just don't think it's a worthwhile change,
because four of the five placeholders there are enforced by the kernel and
therefore the kernel must check them again (maybe it does so anyway when it
opens and validates the file).

What REALLY matters to me is that the current_batch file be readable and I can
get the last batch that was loaded, in a well-known format. Without this, we
go from "inconvenience" to "major design change, must talk to customers and
customers must adapt their workloads". Please help me out here.

--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering