Mon, Oct 19, 2020 at 09:05:34PM CEST, jacob.e.kel...@intel.com wrote: >> -----Original Message----- >> From: David Ahern <dsah...@gmail.com> >> Sent: Saturday, October 17, 2020 8:35 AM >> To: Keller, Jacob E <jacob.e.kel...@intel.com>; netdev@vger.kernel.org; Jiri >> Pirko >> <j...@resnulli.us> >> Cc: Shannon Nelson <snel...@pensando.io> >> Subject: Re: [iproute2-next v3] devlink: display elapsed time during flash >> update >> >> On 10/14/20 4:31 PM, Jacob Keller wrote: >> > For some devices, updating the flash can take significant time during >> > operations where no status can meaningfully be reported. This can be >> > somewhat confusing to a user who sees devlink appear to hang on the >> > terminal waiting for the device to update. >> > >> > Recent changes to the kernel interface allow such long running commands >> > to provide a timeout value indicating some upper bound on how long the >> > relevant action could take. >> > >> > Provide a ticking counter of the time elapsed since the previous status >> > message in order to make it clear that the program is not simply stuck. >> > >> > Display this message whenever the status message from the kernel >> > indicates a timeout value. Additionally also display the message if >> > we've received no status for more than couple of seconds. If we elapse >> > more than the timeout provided by the status message, replace the >> > timeout display with "timeout reached". >> > >> > Signed-off-by: Jacob Keller <jacob.e.kel...@intel.com> >> > --- >> > Changes since v2 >> > * use clock_gettime on CLOCK_MONOTONIC instead of gettimeofday >> > * remove use of timersub since we're now using struct timespec >> > >> > devlink/devlink.c | 105 +++++++++++++++++++++++++++++++++++++++++++++- >> > 1 file changed, 104 insertions(+), 1 deletion(-) >> > >> >> applied to iproute2-next. >> >> The DEVLINK attributes are ridiculously long -- >> DEVLINK_ATTR_FLASH_UPDATE_STATUS_TIMEOUT is 40 characters -- which >> forces really long code lines or oddly wrapped lines. Going forward >> please consider abbreviations on name components to reduce their lengths. > >This is probably a larger discussion, since basically every devlink attribute >name is long. > >Jiri, Jakub, any thoughts on this? I'd like to see whatever abbreviation >scheme we use be consistent.
I prefer long and easy to understand. > >Thanks, >Jake
