On Mar 10, 2007, at 8:48 AM, Jason Thorpe wrote:

>> In the former case, ipl_t could be a char, and in the latter
>> it should be uint16_t. Anyway I don't think there is any reason
>> it should be an int.
>>
>> (should we use the same way among all m68k ports?)

I have a patch in my local tree that makes ipl_cookie_t 16-bits (to  
hold an SR value or an IPL_* constant), which allows me to make the  
change I want to make to kmutex_t on m68k (which shrinks it down to 8  
bytes).

I left ipl_t alone in case it is used in any assembly code (I don't  
think it is, but I didn't want to break anything just in case).

Tsutsui-san and John Klos are testing some kernels for me, and once I  
hear good feedback on that, I will check in my changes that:

- Shrink ipl_cookie_t to 16-bits.
- Shrink kmutex_t to 8 bytes.
- Implement a RAS-based compare-and-swap for sun2 so that mutexes will  
work on that platform.

-- thorpej