From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Michael Schmitz <schmitzmic@gmail.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Finn Thain <fthain@telegraphics.com.au>
Cc: Andreas Schwab <schwab@linux-m68k.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
linux-m68k <linux-m68k@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware
Date: Mon, 11 Jun 2018 10:05:22 +1000 [thread overview]
Message-ID: <22a505e0f094352b9cb883935fae9f494fb2cb0b.camel@kernel.crashing.org> (raw)
In-Reply-To: <3187b544-e265-dfd9-e0e3-e2a742c190d5@gmail.com>
On Sun, 2018-06-10 at 21:12 +1200, Michael Schmitz wrote:
> Hi Geert,
Top posting, sorry ...
We are painting that bike shed with way too many coats..
We can keep the existing definitions, stick a comment on them stating
"obsolete" and use new number if/when needed.
Ben.
> Am 10.06.2018 um 20:29 schrieb Geert Uytterhoeven:
> > Hi Finn,
> >
> > On Sat, Jun 9, 2018 at 2:20 PM Finn Thain <fthain@telegraphics.com.au> wrote:
> > > > > > Is this enum used by any user space code? If so, perhaps rather
> > > > > > leave the PMU_68K_V1 in there to avoid upsetting that?
> > > > >
> > > > > It also changes the value of PMU_68K_V2, which is an ABI break.
> > > >
> > > > Yes, that's what I worry about - but do we know of any users of that
> > > > particular interface?
> > >
> > > There is no ABI issue AFAIK. The value of pmu_kind is visible to userland
> > > only on powerpc. /dev/pmu and /proc/pmu/* do not exist on m68k. This patch
> > > series will make these UAPIs available on m68k, and for that reason I've
> > > chosen the value PMU_UNKNOWN for pmu_kind.
> >
> > While /dev/pmu and /proc/pmu/* may not exist on m68k, definitions in
> > include/uapi/linux/pmu.h are part of the ABI, and cannot be changed or removed,
> > unless we are 100% sure there are no users.
> >
> > If I would write a program interfacing with /dev/pmu and /proc/pmu/*, and
> > needing to check the PMU type, it would have a switch() statement with
> > all existing values defined in <linux/pmu.h>. So that would become broken
> > by your change.
> >
> > Hence the enum is append-only.
>
> The PMU type from pmu.h was never exposed to user space on m68k via
> /proc/pmu/*, and /dev/pmu is used for ioctls to the PMU driver on
> powerpc only (the 68k PMU driver doesn't have ioctl support). No way
> that I can see for user space to make use of the PMU type definition
> from pmu.h, so I suppose we can be sure there are no users.
>
> The m68k PMU types cannot be said to be exposed on powerpc either (which
> has ioctl support to interrogate the PMU type), as these only return
> values up to PMU_KEYLARGO_BASED.
>
> Applications like pbbuttonsd or pmud don't use the kernel PMU type at
> all, but go straight to the PMU via the ADB bus to interrogate the
> hardware type, so won't be affected either.
>
> Is there any other way besides procfs and ioctl for user space to
> interrogate the PMU type that I'm missing here?
>
> (I understand that breaking the ABI should not be done as a rule, but
> this may be a case where we can successfully argue the definitions were
> never in use, so the rules may be bent a little).
next prev parent reply other threads:[~2018-06-11 0:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1528423341.git.fthain@telegraphics.com.au>
[not found] ` <d9d626ca4e7ac9c7e81b24a34f5fbcae9d1d5046.1528423341.git.fthain@telegraphics.com.au>
[not found] ` <9f015684-4d91-70e4-d2a4-89fe167ff8ab@gmail.com>
[not found] ` <m2h8mc4ejw.fsf@linux-m68k.org>
[not found] ` <e1006b0a-a429-4744-7525-203cb91f1d5f@gmail.com>
[not found] ` <alpine.LNX.2.21.1806092140410.26@nippy.intranet>
2018-06-10 6:55 ` [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware Benjamin Herrenschmidt
2018-06-11 23:47 ` Finn Thain
2018-06-12 6:53 ` Laurent Vivier
2018-06-12 20:12 ` Michael Schmitz
[not found] ` <CAMuHMdUHnFKzhe3x3=bG63HwnM7psu7AA=nba8q+nTDnxBAryw@mail.gmail.com>
[not found] ` <3187b544-e265-dfd9-e0e3-e2a742c190d5@gmail.com>
2018-06-11 0:05 ` Benjamin Herrenschmidt [this message]
2018-06-11 1:45 ` Michael Schmitz
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=22a505e0f094352b9cb883935fae9f494fb2cb0b.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=fthain@telegraphics.com.au \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=schmitzmic@gmail.com \
--cc=schwab@linux-m68k.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).