Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with
--iK/U8+IrLmbLL9vI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Nov 05, 2011 at 03:00:58PM -0500, Alan Cox wrote:
> On 11/05/2011 10:15, Kostik Belousov wrote:
> >On Sat, Nov 05, 2011 at 07:37:48AM -0700, mdf@freebsd.org wrote:
> >>On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov<kostikbel@gmail.com> =
=20
> >>wrote:
> >>>On Fri, Nov 04, 2011 at 06:03:39PM +0200, Kostik Belousov wrote:
> >>>
> >>>Below is the KBI patch after vm_page_bits_t merge is done.
> >>>Again, I did not spent time converting all in-tree consumers
> >>>from the (potentially) loadable modules to the new KPI until it
> >>>is agreed upon.
> >>I like my bikeshed orange...
> >>
> >>I would think a more canonical name would be get/set rather than
> >>read/write, especially since these operations aren't reading and
> >>writing the page (neither are they getting the page, but at least set
> >>is pretty unambiguous).
> >Look at the vm_page.h:385. vm_page_set_valid() is already taken.
>=20
> I don't feel good about creating an interface under which we have=20
> functions named vm_page_set_valid() and vm_page_write_valid(). I think=
=20
> that we should take a step back and look at the whole of set of=20
> functions that exist for manipulating the page's valid and dirty field=20
> and see if we can come up with a logical schema for naming them. I=20
> wouldn't then be surprised if this results in renaming some of the=20
> existing functions.
>=20
> However, this should not delay the changes to address the vm_page_lock=20
> problem. I had two questions about that part of your patch. First, is=
=20
> there any reason that you didn't include vm_page_lockptr()? If we=20
> created the page locking macros that you, jhb@, and I were talking about=
=20
> last week, then vm_page_lockptr() would be required. Second, there=20
> seems to be precedent for naming the locking functions _vm_page_lock()=20
> instead of vm_page_lock_func(), for example, the mutex code, i.e.,=20
> sys/mutex.h, and the vm map locking functions.
I think vm_page_lockptr() should be included when some kind of
reloc-iterating macros are actually introduced into the tree. And,
I have a hope that they can be wrapped around a function with the
signature like
void vm_page_relock(vm_page_t locked_page, vm_page_t unlocked_page);
which moves the lock from locked_page to unlocked_page.
Regarding the _vm_page_lock() vs. vm_page_lock_func(), the mutex.h has
a lot of violations in regard of the namespaces, IMO. The __* namespace
is reserved for the language implementation, so our freestanding program
(kernel) ignores the requirements of the C standard with the names like
__mtx_lock_spin(). Using the name _vm_page_lock() is valid, but makes
it not unreasonable for other developers to introduce reserved names.
So I decided to use the suffixes. vm_map.h locking is free of these
violations.
--iK/U8+IrLmbLL9vI
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk62gPMACgkQC3+MBN1Mb4hMmQCeNIkyDL5uP3ZfnsmDyF0/vRFn
X3QAnAo1an3qCsI+jdgUxl9Pk6ZTMDFV
=MZ3u
-----END PGP SIGNATURE-----
--iK/U8+IrLmbLL9vI--
討論串 (同標題文章)
完整討論串 (本文為第 4 之 37 篇)：