> 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.
---
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