Date: Fri, 18 Nov 2011 14:51:28 +0100 From: Attilio Rao <attilio@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: mdf@freebsd.org, "K. Macy" <kmacy@freebsd.org>, Alan Cox <alc@rice.edu>, Andriy Gapon <avg@freebsd.org>, freebsd-current@freebsd.org, Benjamin Kaduk <kaduk@mit.edu>, Penta Upa <bsdboot@gmail.com> Subject: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3] Message-ID: <CAJ-FndCZqwvbi2N=f=5TxkHH3gaKAGxipPoHBCFLqF=sLOTqdQ@mail.gmail.com> In-Reply-To: <CAJ-FndAULb9r-FVaBparSJVtoSEQuX7%2BwhCoBNdQi7n%2B=UpEdA@mail.gmail.com> References: <20111105141306.GW50300@deviant.kiev.zoral.com.ua> <CAMBSHm86TaJnRRgmPA_t7tiPfQsPyoTqz3ymdHSY1H3t5G864Q@mail.gmail.com> <20111105151530.GX50300@deviant.kiev.zoral.com.ua> <4EB595FA.4020500@rice.edu> <20111106124331.GP50300@deviant.kiev.zoral.com.ua> <4EB81942.70501@rice.edu> <20111107193516.GA50300@deviant.kiev.zoral.com.ua> <CAJ-FndDsrVk7EjjtE=QuhaJE1_k7Q1BvQ%2BxriJPnGzLXJQr1sg@mail.gmail.com> <20111116084542.GY50300@deviant.kiev.zoral.com.ua> <CAJ-FndAwWzFJgpCdaaE=YkipZSCtE6Vb8-LEK2_qS=bVhRM3OQ@mail.gmail.com> <20111118105224.GB50300@deviant.kiev.zoral.com.ua> <CAJ-FndAULb9r-FVaBparSJVtoSEQuX7%2BwhCoBNdQi7n%2B=UpEdA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/11/18 Attilio Rao <attilio@freebsd.org>: > 2011/11/18 Kostik Belousov <kostikbel@gmail.com>: >> On Fri, Nov 18, 2011 at 11:40:28AM +0100, Attilio Rao wrote: >>> 2011/11/16 Kostik Belousov <kostikbel@gmail.com>: >>> > On Tue, Nov 15, 2011 at 07:15:01PM +0100, Attilio Rao wrote: >>> >> 2011/11/7 Kostik Belousov <kostikbel@gmail.com>: >>> >> > On Mon, Nov 07, 2011 at 11:45:38AM -0600, Alan Cox wrote: >>> >> >> Ok. =C2=A0I'll offer one final suggestion. =C2=A0Please consider = an alternative >>> >> >> suffix to "func". =C2=A0Perhaps, "kbi" or "KBI". =C2=A0In other w= ords, something >>> >> >> that hints at the function's reason for existing. >>> >> > >>> >> > Sure. Below is the extraction of only vm_page_lock() bits, togethe= r >>> >> > with the suggested rename. When Attilio provides the promised simp= lification >>> >> > of the mutex KPI, this can be reduced. >>> >> >>> >> My tentative patch is here: >>> >> http://www.freebsd.org/~attilio/mutexfileline.patch >>> >> >>> >> I need to make more compile testing later, but it already compiles >>> >> GENERIC + modules fine on HEAD. >>> >> >>> >> The patch provides a common entrypoint, option independent, for both >>> >> fast case and debug/compat case. >>> >> Additively, it almost entirely fixes the standard violation of the >>> >> reserved namespace, as you described (the notable exception being th= e >>> >> macro used in the fast path, that I want to fix as well, but in a >>> >> separate commit). >>> >> >>> >> Now the file/line couplet can be passed to the "_" suffix variant of >>> >> the flag functions. >>> > Yes, this is exactly KPI that I would use when available for the >>> > vm_page_lock() patch. >>> > >>> >> >>> >> eadler@ reviewed the mutex.h comment. >>> >> >>> >> Please let me know what you think about it, as long as we agree on t= he >>> >> patch I'll commit it. >>> > But I also agree with John that imposing large churn due to the elimi= nation >>> > of the '__' prefix is too late now. At least it will make the change >>> > non-MFCable. Besides, we already lived with the names for 10+ years. >>> > >>> > I will be happy to have the part of the patch that exports the mtx_XX= X_(mtx, >>> > file, line) defines which can be used without taking care of LOCK_DEB= UG >>> > or MUTEX_NOINLINE in the consumer code. >>> >>> Ok, this patch should just add the compat stub: >>> http://www.freebsd.org/~attilio/mutexfileline2.patch >> Am I right that I would use mtx_lock_(mtx, file, line) etc ? >> If yes, I am fine with it. > > Yes that is correct. > > However, I'm a bit confused on one aspect: would you mind using > _mtx_lock_flags() instead? > If you don't mind the "underscore namespace violation" I think I can > make a much smaller patch against HEAD for it. > > Otherwise, the one now posted should be ok. After thinking more about it, I think that is basically the shorter version I can came up with. Please consider: http://www.freebsd.org/~attilio/mutexfileline2.patch as a possible commit candidate for me. Attilio --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndCZqwvbi2N=f=5TxkHH3gaKAGxipPoHBCFLqF=sLOTqdQ>