All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"cross-distro@lists.linaro.org" <cross-distro@lists.linaro.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Serban Constantinescu <Serban.Constantinescu@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"ghackmann@google.com" <ghackmann@google.com>,
	"ijc@hellion.org.uk" <ijc@hellion.org.uk>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: Re: [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo
Date: Fri, 24 Oct 2014 15:24:35 +0100	[thread overview]
Message-ID: <20141024142435.GK24265@leverpostej> (raw)
In-Reply-To: <20141024141936.GS27405@n2100.arm.linux.org.uk>

On Fri, Oct 24, 2014 at 03:19:36PM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 24, 2014 at 02:56:39PM +0100, Mark Rutland wrote:
> > Currently, the arm64 /proc/cpuinfo format differs from that of arm, in a
> > manner which prevents some otherwise portable applications from
> > functioning as expected. Specifically, the "Features" line describes the
> > 64-bit hwcaps exclusive of the 32-bit hwcaps, which causes issues for
> > certain applications which attempt to parse /proc/cpuinfo to detect
> > features rather than directly using the hwcaps exposed via auxval.
> 
> Like it or not, but every file in procfs is a userspace API, and can
> be parsed by any program.  If we change a procfs file and a userspace
> program then stops working, that's our fault, and our problem to fix
> (by restoring the information published there in a manner which
> userspace can parse.)
> 
> So, as you've found some programs which rely on this, ARM64 really does
> need to be compatible with ARM32 in this respect.

I agree, hence this RFC.

The key question is how we fix the arm64 /proc/cpuinfo format to make
those programs function, without potentially breaking other
applications.

> It's unfortunate that people have decided that parsing the ELF HWCAPs
> from /proc/cpuinfo is an acceptable way to go, rather than using the
> binary information passed, but procfs is a much more visible source
> of information than some binary interface which you need to read man
> pages to find.
> 
> That's the danger of publishing information in either procfs or sysfs.
> Once published, it becomes part of the userspace API, and it can become
> hard to remove it.  This is why we should /always/ think very carefully
> about what we expose through these filesystems.

Yes. We made a mistake here with the arm64 format. Hopefully there's a
way by which we can keep applications happy.

For future architectures, it's probably worth putting stronger
guidelines in place to prevent precisely the issues we've hit here.

Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"cross-distro-cunTk1MwBs8s++Sfvej+rw@public.gmane.org"
	<cross-distro-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
	Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>,
	Serban Constantinescu
	<Serban.Constantinescu-5wv7dgnIgG8@public.gmane.org>,
	Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"ghackmann-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org"
	<ghackmann-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	"ijc-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org"
	<ijc-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	"linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo
Date: Fri, 24 Oct 2014 15:24:35 +0100	[thread overview]
Message-ID: <20141024142435.GK24265@leverpostej> (raw)
In-Reply-To: <20141024141936.GS27405-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>

On Fri, Oct 24, 2014 at 03:19:36PM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 24, 2014 at 02:56:39PM +0100, Mark Rutland wrote:
> > Currently, the arm64 /proc/cpuinfo format differs from that of arm, in a
> > manner which prevents some otherwise portable applications from
> > functioning as expected. Specifically, the "Features" line describes the
> > 64-bit hwcaps exclusive of the 32-bit hwcaps, which causes issues for
> > certain applications which attempt to parse /proc/cpuinfo to detect
> > features rather than directly using the hwcaps exposed via auxval.
> 
> Like it or not, but every file in procfs is a userspace API, and can
> be parsed by any program.  If we change a procfs file and a userspace
> program then stops working, that's our fault, and our problem to fix
> (by restoring the information published there in a manner which
> userspace can parse.)
> 
> So, as you've found some programs which rely on this, ARM64 really does
> need to be compatible with ARM32 in this respect.

I agree, hence this RFC.

The key question is how we fix the arm64 /proc/cpuinfo format to make
those programs function, without potentially breaking other
applications.

> It's unfortunate that people have decided that parsing the ELF HWCAPs
> from /proc/cpuinfo is an acceptable way to go, rather than using the
> binary information passed, but procfs is a much more visible source
> of information than some binary interface which you need to read man
> pages to find.
> 
> That's the danger of publishing information in either procfs or sysfs.
> Once published, it becomes part of the userspace API, and it can become
> hard to remove it.  This is why we should /always/ think very carefully
> about what we expose through these filesystems.

Yes. We made a mistake here with the arm64 format. Hopefully there's a
way by which we can keep applications happy.

For future architectures, it's probably worth putting stronger
guidelines in place to prevent precisely the issues we've hit here.

Mark.

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo
Date: Fri, 24 Oct 2014 15:24:35 +0100	[thread overview]
Message-ID: <20141024142435.GK24265@leverpostej> (raw)
In-Reply-To: <20141024141936.GS27405@n2100.arm.linux.org.uk>

On Fri, Oct 24, 2014 at 03:19:36PM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 24, 2014 at 02:56:39PM +0100, Mark Rutland wrote:
> > Currently, the arm64 /proc/cpuinfo format differs from that of arm, in a
> > manner which prevents some otherwise portable applications from
> > functioning as expected. Specifically, the "Features" line describes the
> > 64-bit hwcaps exclusive of the 32-bit hwcaps, which causes issues for
> > certain applications which attempt to parse /proc/cpuinfo to detect
> > features rather than directly using the hwcaps exposed via auxval.
> 
> Like it or not, but every file in procfs is a userspace API, and can
> be parsed by any program.  If we change a procfs file and a userspace
> program then stops working, that's our fault, and our problem to fix
> (by restoring the information published there in a manner which
> userspace can parse.)
> 
> So, as you've found some programs which rely on this, ARM64 really does
> need to be compatible with ARM32 in this respect.

I agree, hence this RFC.

The key question is how we fix the arm64 /proc/cpuinfo format to make
those programs function, without potentially breaking other
applications.

> It's unfortunate that people have decided that parsing the ELF HWCAPs
> from /proc/cpuinfo is an acceptable way to go, rather than using the
> binary information passed, but procfs is a much more visible source
> of information than some binary interface which you need to read man
> pages to find.
> 
> That's the danger of publishing information in either procfs or sysfs.
> Once published, it becomes part of the userspace API, and it can become
> hard to remove it.  This is why we should /always/ think very carefully
> about what we expose through these filesystems.

Yes. We made a mistake here with the arm64 format. Hopefully there's a
way by which we can keep applications happy.

For future architectures, it's probably worth putting stronger
guidelines in place to prevent precisely the issues we've hit here.

Mark.

  reply	other threads:[~2014-10-24 14:25 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 13:56 [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo Mark Rutland
2014-10-24 13:56 ` Mark Rutland
2014-10-24 13:56 ` Mark Rutland
2014-10-24 13:56 ` [RFC PATCH 1/1] arm64: Fix up /proc/cpuinfo Mark Rutland
2014-10-24 13:56   ` Mark Rutland
2014-10-24 13:56   ` Mark Rutland
2014-10-30 17:15   ` Will Deacon
2014-10-30 17:15     ` Will Deacon
2014-10-30 17:15     ` Will Deacon
2014-10-30 17:20     ` Ian Campbell
2014-10-30 17:20       ` Ian Campbell
2014-10-30 17:20       ` Ian Campbell
2014-10-24 14:19 ` [RFC PATCH 0/1] arm64: Fix /proc/cpuinfo Russell King - ARM Linux
2014-10-24 14:19   ` Russell King - ARM Linux
2014-10-24 14:19   ` Russell King - ARM Linux
2014-10-24 14:24   ` Mark Rutland [this message]
2014-10-24 14:24     ` Mark Rutland
2014-10-24 14:24     ` Mark Rutland
2014-10-24 15:42     ` Russell King - ARM Linux
2014-10-24 15:42       ` Russell King - ARM Linux
2014-10-24 15:42       ` Russell King - ARM Linux
2014-10-28  4:43 ` Greg Hackmann
2014-10-28  4:43   ` Greg Hackmann
2014-11-06 16:43 ` Catalin Marinas
2014-11-06 16:43   ` Catalin Marinas
2014-11-06 16:43   ` Catalin Marinas
2014-11-06 16:54   ` Will Deacon
2014-11-06 16:54     ` Will Deacon
2014-11-06 16:54     ` Will Deacon
2014-11-06 17:05     ` Catalin Marinas
2014-11-06 17:05       ` Catalin Marinas
2014-11-06 17:05       ` Catalin Marinas
2014-11-13 17:48       ` Catalin Marinas
2014-11-13 17:48         ` Catalin Marinas
2014-11-13 17:48         ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141024142435.GK24265@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Serban.Constantinescu@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=cross-distro@lists.linaro.org \
    --cc=ghackmann@google.com \
    --cc=ijc@hellion.org.uk \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.