svn commit: r313352 - in head/sys: compat/cloudabi compat/freebsd32 compat/linux vm
John Baldwin
jhb at freebsd.org
Tue Feb 7 17:58:38 UTC 2017
On Tuesday, February 07, 2017 12:55:08 PM Edward Tomasz Napierala wrote:
> On 0207T1039, Konstantin Belousov wrote:
> > On Mon, Feb 06, 2017 at 03:03:11PM -0800, John Baldwin wrote:
> > > On Monday, February 06, 2017 08:57:12 PM Edward Tomasz Napierala wrote:
> > > > Author: trasz
> > > > Date: Mon Feb 6 20:57:12 2017
> > > > New Revision: 313352
> > > > URL: https://svnweb.freebsd.org/changeset/base/313352
> > > >
> > > > Log:
> > > > Add kern_vm_mmap2(), kern_vm_mprotect(), kern_vm_msync(), kern_vm_munlock(),
> > > > kern_vm_munmap(), and kern_vm_madvise(), and use them in various compats
> > > > instead of their sys_*() counterparts.
> > > >
> > > > Reviewed by: ed, dchagin, kib
> > > > MFC after: 2 weeks
> > > > Sponsored by: DARPA, AFRL
> > > > Differential Revision: https://reviews.freebsd.org/D9378
> > >
> > > I know kib@ suggested kern_vm_<foo> instead of the vm_<foo> you had suggested,
> > > but just kern_<foo> would be more consistent. That is what we have done with
> > > every other system call. (e.g. there isn't kern_socket_bind, kern_socket_listen,
> > > etc., but just kern_bind() and kern_listen()).
> >
> > Note that the kern_vm_* functions are not quite regular syscall helpers.
> > The big issue with them, which caused my suggestion, is that the
> > functions cannot be declared in sys/syscallsubr.h, because their
> > declarations depend on the vm/*.h namespace.
>
> Exactly; they use vm-specific types (vm_offset_t, for example). And I
> wanted to avoid changing the types all over the place, at least for now.
You would only need <vm/vm.h> though right? None of the actual objects
are used, just things like vm_prot_t?
OTOH, kern_* is currently only used for things that are syscall implementations
and generally take syscall arguments directly (or close approximations of
syscall arguments). It is annoying to lose the consistency in meaning.
--
John Baldwin
More information about the svn-src-head
mailing list