On 2/6/25 9:47 AM, Avri Altman wrote:
On 2/6/25 12:54 AM, Avri Altman wrote:
After some further internal discussions: The set conditions are vendor
specific; The device may set it as many times it wants depending on
its criticality. The spec does not define that nor what the host
should do. So there is this concern that some vendors will report
multiple times, while other wont. Hence, reading critical_health = 1
might be misleading. What do you think?
>
Still not sure if you want this to be a counter?
Since the event can be reported multiple times, a counter sounds better
to me than a boolean.
How about emitting a uevent if a critical health condition has been reported by a
UFS device? See also sdev_evt_send().
Thanks for pointing this out.
A ufs event in enum scsi_device_event seems misplaced - looks like it was invented for unit attention codes.
How about calling kobject_uevent() or kobject_uevent_env() directly from the driver?
Please note that emitting a uevent is not the only possible approach for
informing user space code. Emitting a uevent is recommended if the code
that processes an event can be implemented as a shell script. Could it
be more likely that critical health events will be processed by C or C++
code rather than a shell script? If so, how about making the sysfs
attribute that reports the number of critical health events pollable? In
C and C++ code, polling a sysfs attribute requires less code than
listening for uevents.
Thanks,
Bart.
