From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3190 invoked by alias); 14 Feb 2003 19:38:50 -0000 Mailing-List: contact sid-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sources.redhat.com Received: (qmail 3168 invoked from network); 14 Feb 2003 19:38:49 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 14 Feb 2003 19:38:49 -0000 Received: from redhat.com (tooth.toronto.redhat.com [172.16.14.29]) by touchme.toronto.redhat.com (Postfix) with ESMTP id E347580004E; Fri, 14 Feb 2003 14:38:48 -0500 (EST) Message-ID: <3E4D45ED.8020502@redhat.com> Date: Fri, 14 Feb 2003 19:38:00 -0000 From: Dave Brolley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Frank Ch. Eigler" Cc: sid@sources.redhat.com Subject: Re: [patch][rfa]: SID mapper component - wordsize References: <3E4C3122.5040409@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-q1/txt/msg00050.txt.bz2 Frank Ch. Eigler wrote: >brolley wrote: > > > >>[...] The specification >>[4*1000-1010] >>should allow access to the range 4000-4043, however, the upper bound >>is simply being multiplied by the wordsize, resulting in an upper >>bound of 4040. >> >> > >Actually, addresses in the mapper specs are inclusive, not exclusive. >That's why one often sees ranges ending with ...ffff. Plain raw >scaling such inclusive limits doesn't make sense though, so a special >case calculation like yours would make sense. However, care should be >taken not to confuse exclusive vs inclusive bounds. > Right. That's precisely what the patch does. It computes the intended inclusive bounds. >>If the mapper is accessed using wordsized elements, the problem goes >>unnoticed, since the mapper does not check the ending address of the >>range being accessed. >> >> > >That's a peculiar other bug. To be consistent with the byte-oriented >addressing across sid::bus, the size of the access would need to be >included in the checks. > > That's a separate bug (wasn't sure if it was intentional or not) and an exercise for someone's copious spare time :-) Dave