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> In-Reply-To: <98dce77f-b581-93fe-d2d6-ca1e27cd6a95@rice.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170207202222.GE2092>