Re: [PATCH v2 08/12] macintosh/via-pmu68k: Don't load driver on unsupported hardware

From: Michael Schmitz
Date: Sun Jun 10 2018 - 05:32:22 EST


Hi Geert,

Am 10.06.2018 um 20:29 schrieb Geert Uytterhoeven:
Hi Finn,

On Sat, Jun 9, 2018 at 2:20 PM Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> 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).

Cheers,

Michael


New pmu_kind values can be defined as and when the need arises. But that
would imply a useful classification scheme for pre-PCI powerbooks, and I
don't know what that scheme will look like because at this stage there is
neither userland nor kernel code to support backlight, buttons and battery
for pre-PCI powerbooks.

In anycase, the "v1" and "v2" scheme is obviously inadequate when you
consider the range of m68k powerbook models. Also, consider the

New values can be added at the bottom.

out-of-tree adaptation of via-pmu by the Nubus-PMac project, which has
this ABI break:

diff --git a/include/linux/pmu.h b/include/linux/pmu.h
index cafe98d9694..9882a185a52 100644
--- a/include/linux/pmu.h
+++ b/include/linux/pmu.h
@@ -90,6 +90,7 @@ enum {
PMU_HEATHROW_BASED, /* PowerBook G3 series */
PMU_PADDINGTON_BASED, /* 1999 PowerBook G3 */
PMU_KEYLARGO_BASED, /* Core99 motherboard (PMU99) */
+ PMU_NUBUS_BASED, /* 1400, 2300, 5300 */
PMU_68K_V1, /* 68K PMU, version 1 */
PMU_68K_V2, /* 68K PMU, version 2 */
};

That's bad. But as long as the NuBus-PMac project is out-of-tree, the
enum values it uses are not part of the Linux ABI, IMHO.
During upstreaming, PMU_NUBUS_BASED should be moved to the bottom.

Gr{oetje,eeting}s,

Geert