lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 19 Oct 2020 19:05:34 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     David Ahern <dsahern@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>
CC:     Shannon Nelson <snelson@...sando.io>
Subject: RE: [iproute2-next v3] devlink: display elapsed time during flash
 update

> -----Original Message-----
> From: David Ahern <dsahern@...il.com>
> Sent: Saturday, October 17, 2020 8:35 AM
> To: Keller, Jacob E <jacob.e.keller@...el.com>; netdev@...r.kernel.org; Jiri Pirko
> <jiri@...nulli.us>
> Cc: Shannon Nelson <snelson@...sando.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.keller@...el.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.

Thanks,
Jake

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ