On 11/05/2011 10:15, Kostik Belousov wrote:
On Sat, Nov 05, 2011 at 07:37:48AM -0700, m...@freebsd.org wrote:
On Sat, Nov 5, 2011 at 7:13 AM, Kostik Belousov<kostik...@gmail.com> 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.
I don't feel good about creating an interface under which we have
functions named vm_page_set_valid() and vm_page_write_valid(). I think
that we should take a step back and look at the whole of set of
functions that exist for manipulating the page's valid and dirty field
and see if we can come up with a logical schema for naming them. I
wouldn't then be surprised if this results in renaming some of the
existing functions.
However, this should not delay the changes to address the vm_page_lock
problem. I had two questions about that part of your patch. First, is
there any reason that you didn't include vm_page_lockptr()? If we
created the page locking macros that you, jhb@, and I were talking about
last week, then vm_page_lockptr() would be required. Second, there
seems to be precedent for naming the locking functions _vm_page_lock()
instead of vm_page_lock_func(), for example, the mutex code, i.e.,
sys/mutex.h, and the vm map locking functions.
Alan
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
