On 9/17/20 12:46 PM, Jakub Kicinski wrote:
On Wed, 16 Sep 2020 20:02:00 -0700 Shannon Nelson wrote:
Add a timeout element to the DEVLINK_CMD_FLASH_UPDATE_STATUS
netlink message for use by a userland utility to show that
a particular firmware flash activity may take a long but
bounded time to finish.  Also add a handy helper for drivers
to make use of the new timeout value.

UI usage hints:
  - if non-zero, add timeout display to the end of the status line
        [component] status_msg  ( Xm Ys : Am Bs )
      using the timeout value for Am Bs and updating the Xm Ys
      every second
  - if the timeout expires while awaiting the next update,
    display something like
        [component] status_msg  ( timeout reached : Am Bs )
  - if new status notify messages are received, remove
    the timeout and start over

Signed-off-by: Shannon Nelson <snel...@pensando.io>
Minor nits, otherwise LGTM:

Reviewed-by: Jakub Kicinski <k...@kernel.org>

Thanks.



@@ -3052,6 +3054,9 @@ static int devlink_nl_flash_update_fill(struct sk_buff 
*msg,
        if (nla_put_u64_64bit(msg, DEVLINK_ATTR_FLASH_UPDATE_STATUS_TOTAL,
                              total, DEVLINK_ATTR_PAD))
                goto nla_put_failure;
+       if (nla_put_u64_64bit(msg, DEVLINK_ATTR_FLASH_UPDATE_STATUS_TIMEOUT,
+                             timeout, DEVLINK_ATTR_PAD))
+               goto nla_put_failure;
nit: since old kernels don't report this user space has to deal with it
      not being present so I'd be tempted to only report it if timeout
      is not 0

Hmmm... Unless there are any other comments on this, I think we can be consistent with the other fields here.


+void devlink_flash_update_timeout_notify(struct devlink *devlink,
+                                        const char *status_msg,
+                                        const char *component,
+                                        unsigned long timeout)
+{
+       __devlink_flash_update_notify(devlink,
+                                     DEVLINK_CMD_FLASH_UPDATE_STATUS,
+                                     status_msg, component, 0, 0, timeout);
nit: did we ever report cmd == UPDATE_STATUS and total == 0?
      could this cause a division by zero in some unsuspecting
      implementation? Perhaps we should pass 1 here?

Yes, there are several examples of this.  The userland devlink.c does a check for total == 0 before calculating the percentage.

sln

Reply via email to