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

[Michael Schmitz <schmitzmic@gmail.com>]

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@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).

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
>