From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7059 Path: news.gmane.org!not-for-mail From: Arnd Bergmann Newsgroups: gmane.comp.lib.glibc.alpha,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.lib.musl.general Subject: Re: [musl] Re: [PATCHv3 00/24] ILP32 support in ARM64 Date: Mon, 16 Feb 2015 20:38:39 +0100 Message-ID: <4247895.OCsFybr21D@wuerfel> References: <20141002155217.GH32147@e104818-lin.cambridge.arm.com> <95765022.dfzNYZrNVS@wuerfel> <20150216175135.GB23507@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Trace: ger.gmane.org 1424115554 4241 80.91.229.3 (16 Feb 2015 19:39:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2015 19:39:14 +0000 (UTC) Cc: "libc-alpha@sourceware.org" , "pinskia@gmail.com" , Marcus Shawcroft , "linux-kernel@vger.kernel.org" , Szabolcs Nagy , Andrew Pinski , "linux-arm-kernel@lists.infradead.org" , musl@lists.openwall.com To: Rich Felker Original-X-From: libc-alpha-return-57040-glibc-alpha=m.gmane.org@sourceware.org Mon Feb 16 20:39:12 2015 Return-path: Envelope-to: glibc-alpha@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YNRVg-0004jw-4h for glibc-alpha@plane.gmane.org; Mon, 16 Feb 2015 20:39:12 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:content-type; q=dns; s=default; b=bwY0buMujyaDJambjYn35W6ZtO3yGOTQyTlqFJXTyuP LXTJj/vn3fXYNkE4RdoEdgLd7r+EyOBZTehi3sRL/H4/mQWrjgFXvwB4m+5NnSMF cN8svFgFeMQhqN/ID5QVb6zqSIJabzUG4ahiE1tbKLLnNQAUG35eweaxkVnFm2Hs = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:content-type; s=default; bh=ExUJSfYhONxSQU6tqaO+5aQnsWY=; b=DA00v79wcHs4GYB3o y0Gl48kz5imorPclhNbPiXBD/GmOPN2jMfd06N3yHtZYtkNeDnV6SadQCfpbHOrn bnW2uR5fv2cuqY882IxH+sPq+nYvMdquJNnjHboh1u3kEQw2zLxZvPjMlAks1ylT CfeUxcRt5CUjcWm86Uu43khikA= Original-Received: (qmail 30951 invoked by alias); 16 Feb 2015 19:39:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Original-Sender: libc-alpha-owner@sourceware.org Original-Received: (qmail 30941 invoked by uid 89); 16 Feb 2015 19:39:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: mout.kundenserver.de User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150216175135.GB23507@brightrain.aerifal.cx> X-UI-Out-Filterresults: notjunk:1; Xref: news.gmane.org gmane.comp.lib.glibc.alpha:49332 gmane.linux.kernel:1888969 gmane.linux.ports.arm.kernel:393613 gmane.linux.lib.musl.general:7059 Archived-At: On Monday 16 February 2015 12:51:35 Rich Felker wrote: > On Mon, Feb 16, 2015 at 06:20:18PM +0100, Arnd Bergmann wrote: > > > Would it really be that hard to do: > > > > > > if (ILP32_on_64_process) tv_nsec = (int)tv_nsec; > > > > > > or similar? That's all that's needed. > > > > > > > In some cases, there may also be a measurable performance penalty > > > > in interpreting a user space data structure manually over copying > > > > it (including the timespec values) in one chunk. > > > > > > I don't think the above would be measurable. > > > > It depends: Copying the structure first and then doing the conversion > > in kernel space on the specific members as you do in the example > > should indeed have a trivial performance impact. However, it is also > > the hardest for driver writers to get right, and it's better not to > > trust them with corner cases like this. > > > > To make it more readable, we would probably introduce a helper function > > that copies the timespec from user space memory to kernel space and > > then does all the checks and conversions as required. However, doing > > separate copies can (depending on the architecture) have a noticeable > > impact. An example for this would be architectures that require setting > > up a page table entry for the user space page in order to access the > > data and then destroy it again afterwards, with the correct TLB flushes. > > > > We can do something like this for the old-style compat handlers that > > use 32-bit time_t, but I'd prefer not to have it in the fast path for > > the native 64-bit time_t on 64-bit architectures. > > I know this isn't the place to discuss large architectural kernel > changes, but it would be really nice if the kernel had proper abstract > knowledge, at syscall entry time, what regions of memory from > userspace the syscall is going to need and a way of marshalling them > all together as prep for enterring the code that implements the > syscalls, and if conversion between different ABIs could take place > mostly automatically at this layer. Perhaps this kind of thing is an > idea that could be kept open for the future. I suspect the > combinatorics of different legacy interfaces are going to continue > getting worse, and it would be much nicer to have the support factored > out of the actual syscall implementations. Some subsystems (e.g. v4l) do this in their ioctls, and it sounds like a nice idea, but as I count 17457 instances of copy_{to,from}_user or {get,put}_user in the kernel, I believe we are basically stuck with the current way. > > > Generally I would think the kernel knows the model the process is > > > using, but if not, all you need is separate ioctl numbers for > > > userspace to use depending on which definition it's using. > > > > I've checked now, and indeed the kernel knows for ilp32 x86 and arm, since > > it uses a different ELF interpreter. I thought it might be running the > > ilp32 binaries as ELF64, but it does not. > > This would result in lots of problems like argv[], auxv[], envp[], > etc. being in the wrong format. Right. It depends a bit on the scope though: My impression is that a lot of people who ask for ilp32 mode on arm64 are just interested in getting to work one or two applications. If that was the only goal, they could work around the problem (mostly) in user space, but as it turns out, the kernel patch is doing the entire job of implementing the new ABI at syscall level to the point where you can (mostly) just recompile all of user space. Arnd