[Pdbg] [PATCH] libpdbg: progress bars!

Alistair Popple alistair at popple.id.au
Thu May 17 13:49:20 AEST 2018


Actually I think we should just implement the progress_tick callback Amitay
suggested as it shouldn't be hard to do. I am happy to rework your V2 series to
do that if you don't have any objection Joel?

- Alistair

On Wednesday, 16 May 2018 12:13:56 PM AEST Alistair Popple wrote:
> On Friday, 11 May 2018 4:29:19 PM AEST Joel Stanley wrote:
> > On 11 May 2018 at 16:23, Amitay Isaacs <amitay at ozlabs.org> wrote:
> > > On Thu, 2018-05-10 at 16:58 +0930, Joel Stanley wrote:
> > >>  $ pdbg -p 0 getmem 0x8040278 100 > /tmp/log
> > >>  [==================================================] 100%
> > >>
> > >> Signed-off-by: Joel Stanley <joel at jms.id.au>
> > >
> > > This probably belongs to the pdbg tool and not the library.  In that
> > > case we may need a polling interface to library functions to find out
> > > the progress. :-(
> > >
> > > Or, we can register callbacks for progress_tick from pdbg tool and emit
> > > progress_tick from various long operations in the library.
> > 
> > Yeah. I did a v2 of this that makes it optional, as there are plenty
> > of cases where we don't want progress bars.
> > 
> > It is super useful for big transfers though. I recommend doing a getmem
> > with this patch applied; if it's a multi-minute transfer it will
> > predict how long it takes.
> 
> I guess I can take that for now as it seems to be useful and the v2 didn't look
> too invasive, but really I agree with Amitay here - we need some more general
> way of doing this kind of stuff from the library which typically leaves output
> formatting to the application.
> 
> Amitay I can't remember were you looking into some improvements to the way we do
> logging?
> 
> Regards,
> 
> Alistair
> 
> > Cheers,
> > 
> > Joel
> > 
> 
> 
> 




More information about the Pdbg mailing list