From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104275 invoked by alias); 9 Oct 2017 14:07:30 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 104260 invoked by uid 89); 9 Oct 2017 14:07:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-8.0 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=preference, expressed, staying X-HELO: mail-wm0-f48.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version:content-transfer-encoding; bh=Znl4i6O5wejewcF5pH/Ov83LG7MUtPiubE3GP90j0Kg=; b=Rea91guxkjT6O4dy/+zo3Kr3atM9Nk1M1vqpaEUw+YPg0z3qWDyGHJjecdBURWxxOz vYvOyoFR68DxmLg299MIj5XljWgTFlvBAWS1NybDCL3IhQM1D0vFrnCj8B1pML4CncZF Sfdu9uuOyH5eWn25yggg88YoVVrYDpPxzGmcldZVleGXDoDk5+h/2BTCfTWQz5nfypHO vARHG3zPgoZwCcf3XXiB2JZ00Zk1JeXp2S2i5NSp1x8t/qpGn/wZWJ90cGE9ENDIdyqd qonDsyFspCv01PFMA6QYPFwclXYAcx5vwV2feictH9bn9piaoJdAWvzKGcqzMTFVx3cA MNWQ== X-Gm-Message-State: AMCzsaVF7P7oyHehrzNEuekIH57PmJUf9KQu+PVBEJTWtj2P1ybACga6 bEtPlrt7kKsc6ELmEe/djlaR4w== X-Google-Smtp-Source: AOwi7QB6zT11QenEBoIR7uAEGDEQeeNK+HneWdn+3n2Arf232M0hf18oIN3dwn2VffTN34ScMGGHiQ== X-Received: by 10.28.54.154 with SMTP id y26mr9450175wmh.15.1507558045136; Mon, 09 Oct 2017 07:07:25 -0700 (PDT) References: <1504198860-12951-1-git-send-email-Dave.Martin@arm.com> <1504198860-12951-27-git-send-email-Dave.Martin@arm.com> <59D7A4AF.40408@arm.com> <20171006173715.GC3611@e103592.cambridge.arm.com> <878tgkbr6m.fsf@linaro.org> <20171009094930.GD3611@e103592.cambridge.arm.com> User-agent: mu4e 0.9.19; emacs 26.0.60 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Dave Martin Cc: linux-arch@vger.kernel.org, Mark Rutland , libc-alpha@sourceware.org, Ard Biesheuvel , Szabolcs Nagy , Catalin Marinas , Will Deacon , Richard Sandiford , nd@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 26/28] arm64/sve: Add documentation In-reply-to: <20171009094930.GD3611@e103592.cambridge.arm.com> Date: Mon, 09 Oct 2017 14:07:00 -0000 Message-ID: <87376sbejo.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-10/txt/msg00361.txt.bz2 Dave Martin writes: > On Mon, Oct 09, 2017 at 10:34:25AM +0100, Alex Benn=C3=A9e wrote: >> >> Dave Martin writes: >> >> > On Fri, Oct 06, 2017 at 04:43:43PM +0100, Szabolcs Nagy wrote: >> >> On 31/08/17 18:00, Dave Martin wrote: >> >> > +9. System runtime configuration >> >> > +-------------------------------- >> >> > + >> >> > +* To mitigate the ABI impact of expansion of the signal frame, a p= olicy >> >> > + mechanism is provided for administrators, distro maintainers and= developers >> >> > + to set the default vector length for userspace processes: >> >> > + >> >> > +/proc/cpu/sve_default_vector_length >> >> >> >> >> >> elsewhere in the patch series i see >> >> >> >> /proc/sys/abi/sve_default_vector_length >> >> >> >> is this supposed to be the same? >> > >> > Good spot, thanks! >> > >> > /proc/cpu/ was the old location: they should both say /proc/abi/. >> > I'll fix it. >> >> Isn't /sys (or rather sysfs) the preferred location for modern control >> knobs that mirror the kernels object model or is SVE a special case for >> extending /proc? > > I couldn't figure out which kernel object this maps to. There's no > device, no driver. This isn't even per-cpu. Hmm I can see: /sys/devices/system/cpu On both my x86 and arm64 systems - but I guess this is more ABIish than CPU feature related. > sysctl is already used for similar knobs to this one, so I followed that > precedent -- though if someone argues strongly enough it could be > changed. > > Are there already examples of arch controls like this in sysfs? I > wasn't aware of any, but I didn't look all that hard... Given the paucity of the /proc/sys/abi on both systems I guess this sort of knob is rare enough that people haven't expressed a strong preference for sysfs here. I have no objection to staying with /proc/sys/abi/. -- Alex Benn=C3=A9e