From owner-freebsd-arch Sun Jan 13 10:11:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by hub.freebsd.org (Postfix) with SMTP id 63C8737B41D for ; Sun, 13 Jan 2002 10:11:35 -0800 (PST) Received: (qmail 20777 invoked by uid 0); 13 Jan 2002 18:11:33 -0000 Received: from pd9e16c58.dip.t-dialin.net (HELO forge.local) (217.225.108.88) by mail.gmx.net (mp003-rz3) with SMTP; 13 Jan 2002 18:11:33 -0000 Received: from tmm by forge.local with local (Exim 3.30 #1) id 16Pp6r-00018N-00; Sun, 13 Jan 2002 19:11:57 +0100 Date: Sun, 13 Jan 2002 19:11:57 +0100 From: Thomas Moestl To: "Justin T. Gibbs" Cc: freebsd-arch@FreeBSD.ORG Subject: Re: adding more endian conversion and bus space functions Message-ID: <20020113181157.GA451@crow.dom2ip.de> Mail-Followup-To: "Justin T. Gibbs" , freebsd-arch@FreeBSD.ORG References: <20020111005207.GA7246@crow.dom2ip.de> <200201131656.g0DGuJg21488@aslan.scsiguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200201131656.g0DGuJg21488@aslan.scsiguy.com> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 2002/01/13 at 09:56:19 -0700, Justin T. Gibbs wrote: > >3. stream variants of the bus space access functions; these become > > needed in the case where a bus system uses another endianess than > > the process, as is the case with PCI on sparc64. The normal bus > > space functions will perform byte-swapping as appropriate to convert > > the data to the host byte order (supported by hardware on sparc64). > > However if 16- or 32-bit accesses are used for stream data, > > i.e. data that should not be byte-swapped, these functions need be > > used instead. > > These will simply be defined to their non-stream counterparts on > > architectures where bus and processor byte order do not differ, > > i.e. all other currently supported architectures. > > Are you implying that the non-stream variants of certain bus functions > will auto endian convert? Yes. > This would be really bad for drivers that > already perform the endian conversion manually if it is necessary. This > would be akin to having a network board auto-convert all TCP or IP > header information to host order while dma'ing the packet to host memory. > Confusion would abound. PCI is LE. Hiding that from drivers is a > bad thing. The rationale for that is that some architectures (of which UltraSPARC is one) have hardware support for this conversion. Also, the cases where the stream variants are needed are relatively rare compared to those where the existing functions would be used (i.e. the accessed data is interpreted is an integer of the given size), so it usually minimizes the changes that are needed to make drivers work on big-endian architectures. Additionally, it makes it easier to write drivers for devices that are available for bus systems of different endianesses (e.g. hme). These points add up to quite a win IMHO, so I really would like to do it this way. Are there many drivers around that already do their own conversions? To me, it seems that most that are prepared to be used on big-endian systems already rely on the bus space functions to do the appropriate conversions (since on NetBSD, they do so), but I may be wrong. - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message