Date: Sun, 13 Jan 2002 09:56:19 -0700 From: "Justin T. Gibbs" <gibbs@scsiguy.com> To: Thomas Moestl <tmoestl@gmx.net> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: adding more endian conversion and bus space functions Message-ID: <200201131656.g0DGuJg21488@aslan.scsiguy.com> In-Reply-To: Your message of "Fri, 11 Jan 2002 01:52:07 %2B0100." <20020111005207.GA7246@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
>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? 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. -- Justin 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?200201131656.g0DGuJg21488>