Date: Sat, 28 Mar 2015 11:59:09 -0700 From: Davide Italiano <davide@freebsd.org> To: Randall Stewart <rrs@freebsd.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r280785 - in head/sys: kern netgraph/atm/sscop netgraph/atm/uni sys Message-ID: <CACYV=-FBYMN6HoRqtycXMx_CuwDWcLaB_gstK=_P0SkDTFXn_A@mail.gmail.com> In-Reply-To: <201503281250.t2SCoOkt020297@svn.freebsd.org> References: <201503281250.t2SCoOkt020297@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 28, 2015 at 5:50 AM, Randall Stewart <rrs@freebsd.org> wrote: > Author: rrs > Date: Sat Mar 28 12:50:24 2015 > New Revision: 280785 > URL: https://svnweb.freebsd.org/changeset/base/280785 > > Log: > Change the callout to supply -1 to indicate we are not changing > CPU, also add protection against invalid CPU's as well as > split c_flags and c_iflags so that if a user plays with the active > flag (the one expected to be played with by callers in MPSAFE) without > a lock, it won't adversely affect the callout system by causing a corrupt > list. This also means that all callers need to use the macros and *not* > play with the falgs directly (like netgraph used to). > trim [...] > Modified: head/sys/sys/_callout.h > ============================================================================== > --- head/sys/sys/_callout.h Sat Mar 28 12:23:15 2015 (r280784) > +++ head/sys/sys/_callout.h Sat Mar 28 12:50:24 2015 (r280785) > @@ -57,7 +57,8 @@ struct callout { > void *c_arg; /* function argument */ > void (*c_func)(void *); /* function to call */ > struct lock_object *c_lock; /* lock to handle */ > - int c_flags; /* state of this entry */ > + int c_flags; /* User State */ > + int c_iflags; /* Internal State */ > volatile int c_cpu; /* CPU we're scheduled on */ > }; > I skimmed this quickly, and I'm afraid I think this breaks the KBI, increasing size of struct callout. That said, if it's true and you agree, you should at least bump FreeBSD version number. In an ideal world, you should avoid breaking for bugfixes and not architecural changes. -- Davide
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-FBYMN6HoRqtycXMx_CuwDWcLaB_gstK=_P0SkDTFXn_A>