on 15/05/2012 21:27 Konstantin Belousov said the following: > On Tue, May 15, 2012 at 05:21:47PM +0000, Andriy Gapon wrote: >> Author: avg Date: Tue May 15 17:21:46 2012 New Revision: 235480 URL: >> http://svn.freebsd.org/changeset/base/235480 >> >> Log: MFC r230643: stop_scheduler -> td_stopsched Modified: >> stable/9/sys/sys/proc.h >> ============================================================================== >> >> --- stable/9/sys/sys/proc.h Tue May 15 17:11:00 2012 (r235479) >> +++ stable/9/sys/sys/proc.h Tue May 15 17:21:46 2012 (r235480) @@ >> -235,6 >> +235,7 @@ struct thread { short td_locks; /* (k) Count of >> non-spin >> locks. */ short td_rw_rlocks; /* (k) Count of rwlock read >> locks. */ >> short td_lk_slocks; /* (k) Count of lockmgr shared locks. >> */ + short >> td_stopsched; /* (k) Scheduler stopped. */ struct turnstile >> *td_blocked; >> /* (t) Lock thread is blocked on. */ const char *td_lockname; /* (t) >> Name >> of lock blocked on. */ LIST_HEAD(, turnstile) td_contested; /* (q) >> Contested locks. */ >> > Did you verified that there is a gap between td_lk_slocks and td_blocked an > all tier-1 architectures large enough to adopt td_stopsched without > changing the layout of struct thread after the new member ?
I haven't verified that. but I presumed that the gap was either 2 bytes on 32-bit architectures or 6 bytes on 64-bit ones. What is the proper and doable way of verifying this? > If not, this breaks KBI. I can just revert the commit to not risk an obscure breakage. What would you suggest? Thank you for spotting this. -- Andriy Gapon _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "[email protected]"
