From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27688 invoked by alias); 5 Oct 2017 16:53:42 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 27664 invoked by uid 89); 5 Oct 2017 16:53:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Oct 2017 16:53:41 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BD3B180D; Thu, 5 Oct 2017 09:53:39 -0700 (PDT) Received: from armageddon.cambridge.arm.com (armageddon.cambridge.arm.com [10.1.206.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8610D3F53D; Thu, 5 Oct 2017 09:53:37 -0700 (PDT) Date: Thu, 05 Oct 2017 16:53:00 -0000 From: Catalin Marinas To: Dave Martin Cc: linux-arch@vger.kernel.org, libc-alpha@sourceware.org, Ard Biesheuvel , Szabolcs Nagy , gdb@sourceware.org, Yao Qi , Will Deacon , Richard Sandiford , Alan Hayward , Alex =?iso-8859-1?Q?Benn=E9e?= , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 14/28] arm64/sve: Backend logic for setting the vector length Message-ID: <20171005165334.cstx6fszl7shaudg@armageddon.cambridge.arm.com> References: <1504198860-12951-1-git-send-email-Dave.Martin@arm.com> <1504198860-12951-15-git-send-email-Dave.Martin@arm.com> <20170913172911.3ca2h6cpju7etifi@localhost> <20170913190611.GC23415@e103592.cambridge.arm.com> <20170913221123.y4znytmxtplx24m4@localhost> <20171005164229.GX3611@e103592.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171005164229.GX3611@e103592.cambridge.arm.com> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2017-10/txt/msg00014.txt.bz2 On Thu, Oct 05, 2017 at 05:42:29PM +0100, Dave P Martin wrote: > On Wed, Sep 13, 2017 at 03:11:23PM -0700, Catalin Marinas wrote: > > On Wed, Sep 13, 2017 at 08:06:12PM +0100, Dave P Martin wrote: > > > On Wed, Sep 13, 2017 at 10:29:11AM -0700, Catalin Marinas wrote: > > > > On Thu, Aug 31, 2017 at 06:00:46PM +0100, Dave P Martin wrote: > > > > > This patch implements the core logic for changing a task's vector > > > > > length on request from userspace. This will be used by the ptrace > > > > > and prctl frontends that are implemented in later patches. > > > > > > > > > > The SVE architecture permits, but does not require, implementations > > > > > to support vector lengths that are not a power of two. To handle > > > > > this, logic is added to check a requested vector length against a > > > > > possibly sparse bitmap of available vector lengths at runtime, so > > > > > that the best supported value can be chosen. > > > > > > > > > > Signed-off-by: Dave Martin > > > > > Cc: Alex Bennée > > > > > > > > Can this be merged with patch 20? It seems to add the PR_ definitions > > > > which get actually used later when the prctl interface is added. > > > > > > This patch is used both by patch 19 and by patch 20, which I preferred > > > not to merge with each other: ptrace and prctl are significantly > > > different things. > > > > > > The prctl bit definitions are added here because they are the canonical > > > definitions used by both interfaces. The ptrace #defines are based on > > > them. > > > > > > Does it make sense if I merge patch 20 into this one and apply patch 19 > > > on top? This avoide the appearance of prctl #defines with no prctl > > > implementation. > > > > That's fine, you can bring patch 20 forward. If there are other > > non-trivial issues, feel free to ignore my comment. > > I've had a go at this, but I think it's going to be more trouble than > it's worth -- there are other interdependencies between the patches > which make them tricky to reorder. > > I could add a note in the commit message for this patch explaining why > the prctl flag #defines are being added here. What do you think? As I said, it's up to you. A line in the commit message would do. -- Catalin