Date: Sun, 13 Jan 2002 19:11:57 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: adding more endian conversion and bus space functions Message-ID: <20020113181157.GA451@crow.dom2ip.de> In-Reply-To: <200201131656.g0DGuJg21488@aslan.scsiguy.com> References: <20020111005207.GA7246@crow.dom2ip.de> <200201131656.g0DGuJg21488@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020113181157.GA451>