From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sam Ravnborg Subject: Re: [PATCH v2 02/16] sparc/compat: Provide an accurate in_compat_syscall implementation Date: Tue, 26 Jan 2016 18:44:41 +0100 Message-ID: <20160126174441.GA18873@ravnborg.org> References: <20160126062951.GA17107@ravnborg.org> <20160125.225100.1932707129794761764.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20160125.225100.1932707129794761764.davem@davemloft.net> Sender: linux-parisc-owner@vger.kernel.org To: David Miller Cc: luto@kernel.org, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, torvalds@linux-foundation.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, cmetcalf@ezchip.com, linux-parisc@vger.kernel.org, linux-mips@linux-mips.org, sparclinux@vger.kernel.org List-Id: linux-arch.vger.kernel.org On Mon, Jan 25, 2016 at 10:51:00PM -0800, David Miller wrote: > From: Sam Ravnborg > Date: Tue, 26 Jan 2016 07:29:51 +0100 > > > Could you please add a comment about where 0x110 comes from. > > I at least failed to track this down. > > Frankly I'm fine with this. Someone who understands sparc64 can look > at the trap table around entry 0x110 and see: > > tl0_resv10e: BTRAP(0x10e) BTRAP(0x10f) > tl0_linux32: LINUX_32BIT_SYSCALL_TRAP > tl0_oldlinux64: LINUX_64BIT_SYSCALL_TRAP If one realise to look in the trap table in the first place - yes. Adding a short: /* Check if this is LINUX_32BIT_SYSCALL_TRAP */ Would make wonders to readability. Sam From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from asavdk4.altibox.net ([109.247.116.15]:37362 "EHLO asavdk4.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932586AbcAZRos (ORCPT ); Tue, 26 Jan 2016 12:44:48 -0500 Date: Tue, 26 Jan 2016 18:44:41 +0100 From: Sam Ravnborg Subject: Re: [PATCH v2 02/16] sparc/compat: Provide an accurate in_compat_syscall implementation Message-ID: <20160126174441.GA18873@ravnborg.org> References: <20160126062951.GA17107@ravnborg.org> <20160125.225100.1932707129794761764.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160125.225100.1932707129794761764.davem@davemloft.net> Sender: linux-arch-owner@vger.kernel.org List-ID: To: David Miller Cc: luto@kernel.org, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, torvalds@linux-foundation.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, cmetcalf@ezchip.com, linux-parisc@vger.kernel.org, linux-mips@linux-mips.org, sparclinux@vger.kernel.org Message-ID: <20160126174441.W-RO1VLOMxy9Xsiwu2YabkhV6w7ndI2Z1v9GJeEnNbo@z> On Mon, Jan 25, 2016 at 10:51:00PM -0800, David Miller wrote: > From: Sam Ravnborg > Date: Tue, 26 Jan 2016 07:29:51 +0100 > > > Could you please add a comment about where 0x110 comes from. > > I at least failed to track this down. > > Frankly I'm fine with this. Someone who understands sparc64 can look > at the trap table around entry 0x110 and see: > > tl0_resv10e: BTRAP(0x10e) BTRAP(0x10f) > tl0_linux32: LINUX_32BIT_SYSCALL_TRAP > tl0_oldlinux64: LINUX_64BIT_SYSCALL_TRAP If one realise to look in the trap table in the first place - yes. Adding a short: /* Check if this is LINUX_32BIT_SYSCALL_TRAP */ Would make wonders to readability. Sam