From owner-svn-src-all@freebsd.org Tue Feb 7 20:22:33 2017 Return-Path: <owner-svn-src-all@freebsd.org> Delivered-To: svn-src-all@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 4AD73CD5FA8; Tue, 7 Feb 2017 20:22:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 B5CB417A5; Tue, 7 Feb 2017 20:22:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v17KMNXQ083198 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Feb 2017 22:22:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v17KMNXQ083198 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v17KMMeR083197; Tue, 7 Feb 2017 22:22:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 7 Feb 2017 22:22:22 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alan Cox <alc@rice.edu> Cc: John Baldwin <jhb@freebsd.org>, Edward Tomasz Napierala <trasz@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r313352 - in head/sys: compat/cloudabi compat/freebsd32 compat/linux vm Message-ID: <20170207202222.GE2092@kib.kiev.ua> References: <201702062057.v16KvCtI069664@repo.freebsd.org> <20170207083909.GX2092@kib.kiev.ua> <20170207125508.GA62670@brick> <3460210.7qRYCLqZx1@ralph.baldwin.cx> <98dce77f-b581-93fe-d2d6-ca1e27cd6a95@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98dce77f-b581-93fe-d2d6-ca1e27cd6a95@rice.edu> User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" <svn-src-all.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/> List-Post: <mailto:svn-src-all@freebsd.org> List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 07 Feb 2017 20:22:33 -0000 On Tue, Feb 07, 2017 at 12:29:35PM -0600, Alan Cox wrote: > 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. I do not object, but still I want to point out that such arrangement really depends on all Unix-like systems using the same type model (ILP32 or LP64 or both). If we would try to use current kern_* functions from syscallsubr.h for something more involved, like x32, then the assumption breaks and the type puns are spread. In fact, even in the compat32 layer (host native ILP32->LP64), the somewhat incorrect type manipulations are performed, e.g. we represent a binary-native pointer as host' uint32_t type, which is converted to void * for the purpose of kern_ calls. This conversion assumes much more about the platform than only type sizes, e.g. the flat address space with individually addressable bytes and normal arithmetic for pointers. Mach types are somewhat better in this respect, with purposedly used arithmetic types like vm_size_t, vm_offset_t, vm_ooffset_t for address space operations. Again, I do not object but want to note this mismatch.