From owner-svn-src-head@freebsd.org Tue Feb 7 18:29:38 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4807CD59D6; Tue, 7 Feb 2017 18:29:38 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE1E5188; Tue, 7 Feb 2017 18:29:37 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.16.0.17/8.16.0.17) with SMTP id v17ID4K2011489; Tue, 7 Feb 2017 12:29:36 -0600 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp1.rice.edu with ESMTP id 28fkarr0ep-1; Tue, 07 Feb 2017 12:29:36 -0600 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id C0157460E80; Tue, 7 Feb 2017 12:29:35 -0600 (CST) Subject: Re: svn commit: r313352 - in head/sys: compat/cloudabi compat/freebsd32 compat/linux vm To: John Baldwin , Edward Tomasz Napierala References: <201702062057.v16KvCtI069664@repo.freebsd.org> <20170207083909.GX2092@kib.kiev.ua> <20170207125508.GA62670@brick> <3460210.7qRYCLqZx1@ralph.baldwin.cx> Cc: Konstantin Belousov , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Alan Cox Message-ID: <98dce77f-b581-93fe-d2d6-ca1e27cd6a95@rice.edu> Date: Tue, 7 Feb 2017 12:29:35 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <3460210.7qRYCLqZx1@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611190142 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:29:39 -0000 On 02/07/2017 11:55, John Baldwin wrote: > 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_ instead of the vm_ you had suggested, >>>> but just kern_ 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 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. > I tend to agree with John. Why not use the same types for the kern_* parameters as are used in the corresponding args structure? Let the conversion to the Mach VM types happen inside of the function's implementation.