Re: [PATCH] test/cxl-xor-region.sh: remove redundant waitting

[Marc Herbert <Marc.Herbert@linux.intel.com>]

On 2025-05-16 17:23, dan.j.williams@intel.com wrote:

> 
> So the assumption is that interfactive invocation of cxl commands should
> arrange for a stablized snaphshot of the topology state.
> 
>> Now I am facing a problem that cxl command takes a long time to complete
>> when I run it in a udev rule(do some configuration when CXL memdev is
>> added).  I found it is caused by this function: waitting for udev
>> queue's endding but itself is in the queue.  The cxl_wait_probe()
>> function does not seem to allow me to do that.
> 
> Yes, that is a problem.
> 
>> So, the 2nd question is: is it against the spec to run cxl command in
>> a udev rule?
> 
> No we need to find a way to make that work, so I consider this a bug
> report. My initial reaction is that when called from a udev rule cxl-cli
> should honor a new environment variable, perhaps "UDEV_CXL", that
> disables this waiting that is only meant for human interactive mode.
> 

If the distinction between two such "modes" is indeed desired, I don't
think the name should point at the first known use case (UDEV) for
it. For instance, you could also imagine that while some parts of test
code want the current, blocking and "stabilized" behavior, other parts
of some (other) test code want the currently missing), "fast" and
unstable information without waiting. There could be other use cases, so
in general the user interface (if any) should describe what it does, not
who it is for.

Also, why not just a new command line option like cxl --no-wait?
Environment variables are convenient to cut through layers but they are
also invisible which tends to cause debugging nightmares.  Bonus point
when racing against something like else - which is exactly the case
here! I can already feel for the poor soul copying commands from the
logs of some test failure and missing the magic environment
variable(s)... been there, done that.

PS: while... waiting for such a fast/no-wait/unstable option, I see no
reason why systemd would not work.