From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6251 invoked by alias); 1 Aug 2006 13:13:01 -0000 Received: (qmail 6238 invoked by uid 22791); 1 Aug 2006 13:13:01 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 01 Aug 2006 13:12:59 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G7u3I-0002QB-GE; Tue, 01 Aug 2006 09:12:52 -0400 Date: Tue, 01 Aug 2006 13:13:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: Mark Kettenis , eliz@gnu.org, gdb-patches@sources.redhat.com Subject: Re: Flash support part 2: flash programming Message-ID: <20060801131252.GA9084@nevyn.them.org> Mail-Followup-To: Vladimir Prus , Mark Kettenis , eliz@gnu.org, gdb-patches@sources.redhat.com References: <200607201342.30712.vladimir@codesourcery.com> <200607311730.57313.vladimir@codesourcery.com> <200607312221.k6VMLrDf019709@elgar.sibelius.xs4all.nl> <200608010923.25082.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608010923.25082.vladimir@codesourcery.com> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00009.txt.bz2 On Tue, Aug 01, 2006 at 09:23:23AM +0400, Vladimir Prus wrote: > No, this is intentional change. The target_write_memory_blocks uses it, and it > was made explicitly so that we can produce progress report while loading > data. It's currently used by MI frontend, and if target_write_memory_blocks > is coded to call progress reporting routine only at the end of a section, it > will make progress reporting much less usefull. Vlad, I'm a little scared by how many versions of this patch are floating around :-) I have a copy from the internal list on 2006-07-12 which uses target_write_memory instead. And there's also the xfer_partial_using_stratum change we discussed, in order to keep using target_write_memory_partial. But the last suggestion I can find in the discussion was: > But that suggests there's a simpler way to do it. We could break out > target_write into another function, target_write_with_progress, that > takes a progress callback. Have target_write call that without a > callback. Then you could use the new interface to write out large > chunks of data, without having to perform the partial transfers > yourself, or having to do the bookkeeping for the progress bar. > Maybe that would be easier. I think that may be the way to go; I don't really want to re-export target_write_partial if we can avoid it. I realize you're not going to have time to revise these for a while, so I may take care of this, once we're finished with expat. -- Daniel Jacobowitz CodeSourcery