On Mar 10, 2007, at 5:17 AM, Izumi Tsutsui wrote:

>
>> The reason that kmutex_t is 16 bytes on the m68k instead of 8 is
>> because ipl_cookie_t is an int.  If it could be made smaller (say, a
>> short or a char), mtx_ipl and mtx_lock could overlay their storage
>> with mtx_owner (they way x86 does).
>>
>> So, which platforms are storing the big values in ipl_cookie_t?
>> Actually, it looks like nobody is, because the m68k SR is only 16- 
>> bit,
>> yes?
>
> On some ports ipl_cookie_t contains ipl_t _ipl which is used
> as index to pick up SR values.

Yes, but those indices are even smaller than SR values.

>
> ---
> typedef int ipl_t;
> typedef struct {
>    ipl_t _ipl;
> } ipl_cookie_t;
>
> static inline ipl_cookie_t
> makeiplcookie(ipl_t ipl)
> {
>
>    return (ipl_cookie_t){._ipl = ipl};
> }
>
> static inline int
> splraiseipl(ipl_cookie_t icookie)
> {
>
>    return _splraise(ipl2spl_table[icookie._ipl]);
> }
> ---
>
> On other ports ipl_cookie_t contains ipl_t _psl which is used
> to pass (static) SR values to _splraise() directly in splraiseipl().
> ---
> typedef int ipl_t;
> typedef struct {
>    int _psl;
> } ipl_cookie_t;
>
> static inline ipl_cookie_t
> makeiplcookie(ipl_t ipl)
> {
>
>    return (ipl_cookie_t){._psl = hp300_ipl2psl[ipl]};
> }
>
> static inline int
> splraiseipl(ipl_cookie_t icookie)
> {
>
>    return _splraise(icookie._psl);
> }
> ---
>
> 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?)
> ---
> Izumi Tsutsui

-- thorpej