From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20603 invoked by alias); 27 Feb 2008 15:39:27 -0000 Received: (qmail 20591 invoked by uid 22791); 27 Feb 2008 15:39:25 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 27 Feb 2008 15:39:08 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1JUON5-0003gG-00; Wed, 27 Feb 2008 15:39:03 +0000 Received: from perivale.mips.com ([192.168.192.200]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1JUOMw-0005p7-00; Wed, 27 Feb 2008 15:38:54 +0000 Received: from macro (helo=localhost) by perivale.mips.com with local-esmtp (Exim 4.63) (envelope-from ) id 1JUOMw-0002XJ-Ii; Wed, 27 Feb 2008 15:38:54 +0000 Date: Wed, 27 Feb 2008 15:43:00 -0000 From: "Maciej W. Rozycki" To: Jim Blandy cc: gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: testsuite: Of all the timeouts provided always select the largest In-Reply-To: <8f2776cb0802260824y2c87f942sa925149de3c38cef@mail.gmail.com> Message-ID: References: <8f2776cb0802260755q7c48c3d9me8d35807c3d35ae7@mail.gmail.com> <8f2776cb0802260824y2c87f942sa925149de3c38cef@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: macro@mips.com Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-02/txt/msg00434.txt.bz2 On Tue, 26 Feb 2008, Jim Blandy wrote: > > All the callers would have to be updated and unfortunately the dependency > > may not necessarily be linear. For example for a fast target accessed > > through a slow port the factor for transferring data through, such as > > downloading a program image, would have to be higher than for a slow > > target accessed through a fast port. Contrariwise the factor applied to > > actions involving execution on the respective systems. In general I do > > agree it is a good idea, but that is a lot of work that best be well > > thought before commencing. > > All true, except for the "all callers" part, I think: couldn't > gdb_expect recognize a '-timeout-factor' flag as its first argument? > Then we could update call sites as we came across them. > > It's certainly not linear, but linear is better than constant, surely. > For the sake of setting timeouts, we only need an upper bound. Hmm, I have given it a little bit more thought and I believe it may be reasonable for boards to provide their own factors for classes of operations, let's say two for a start, corresponding to tranfer and execution latencies as noted above. Then each of calling sites might use one of them according to operation performed, together, possibly, with a factor specific to the requested operation which the class factor would be multiplied by. I am not sure if that is not too complicated, but it would better match the reality. All the factors might default to 1 for simplicity as could call sites with no class annotation (your flag might become '-timeout-class'). Any thoughts? Maciej