Re: kern/51492: rasops byte order issue

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

The following reply was made to PR kern/51492; it has been noted by GNATS.

From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/51492: rasops byte order issue
Date: Wed, 21 Sep 2016 17:24:25 +0300

 As far as I udnerstand macallan@ suggestion for the new flag, we
 already de-facto use RI_BSWAP like that in 2- 4- and 8-bit rasops.
 
 For rasops8 I originally did the following back in 2002:
 
 #if BYTE_ORDER == BIG_ENDIAN
 #define NEED_LITTLE_ENDIAN_STAMP RI_BSWAP
 #else
 #define NEED_LITTLE_ENDIAN_STAMP 0
 #endif
     if ((ri->ri_flg & RI_BSWAP) == NEED_LITTLE_ENDIAN_STAMP) {
       /* make little endian stamp */
     } else {
       /* make big endian stamp */
     }
 
 which kiyohara@ later used for 2- and 4- too.
 
 That code should probaly be simplified by building the stamp once and
 using bswap() instead of spelling out the stamp building code twice.
 
 For rasops15.c the logic is somewhat obscured by the fact that bswap()
 is applied to the stamp in rasops.c.  It should use the logic like in
 rasops8.c except that it can build the stamp once and let bswap do the
 right thing (as suggested in the previous paragraph for 8-bit).
 
 rasops24 seems to do a combination of static and dynamic checks and
 that hints that it probably must be wrong for some combinations of
 endianness and RI_BSWAP.
 
 So in general I think that macallan@ proposal is basicaly right, but
 that the new flag is not needed and instead existing RI_BSWAP should
 be fixed.  Then fb driver attach code can just use a macro like
 
     rasops_byte_order(ri, BIG_ENDIAN); // this fb is big endian
 
 which will statically expand to nothing or to setting RI_BSWAP
 depending on cpu's endianness.
 
 -uwe