ACK/Cmnt: [SRU][H/raspi][PATCH] UBUNTU: [Config] raspi: Set BCM_VCIO=y

[Tim Gardner]

On 5/11/21 3:26 AM, Stefan Bader wrote:
> On 11.05.21 09:13, Juerg Haefliger wrote:
>> On Tue, 11 May 2021 08:20:24 +0200
>> Stefan Bader <stefan.bader at canonical.com> wrote:
>>
>>> On 10.05.21 15:22, Juerg Haefliger wrote:
>>>> On Mon, 10 May 2021 06:15:56 -0600
>>>> Tim Gardner <tim.gardner at canonical.com> wrote:
>>>>> Acked-by: Tim Gardner <tim.gardner at canonical.com>
>>>>>
>>>>> Don't you also have to drop vcio from the ABI files lest you get the
>>>>> always amusing build failure message "EE: Missing modules (start 
>>>>> begging
>>>>> for mercy)".
>>>>
>>>> Yes. But if I include that change in this patch then it is dropped 
>>>> during
>>>> cranky open. Which reminds me that I should work on a cranky open 
>>>> fix for
>>>> that... And we should fix the ABI check to not complain about 'm' -> 
>>>> 'y'
>>>> changes (which is also on my todo list somewhere).
>>>
>>> Not really needed.
>>
>> I beg to disagree.
>>
>>
>>> If the changes which drop modules from abi files are there
>>> one can just move the open commit before the patch that modifies the 
>>> abi.
>>
>> Which is a rebase and we can't force-push the main kernels, or can we? 
>> And
>> the cranker needs to realize that the open commit has to be moved...
>>
>>
>>> Of
>>> course one could put such a logic into open. On the other hand I have 
>>> the
>>> feeling the more we put into tools the less people will double check 
>>> what they
>>> do or even know it. I know that volume more and more requires doing 
>>> things
>>> quickly but making everything handled automatically maybe will make 
>>> us pay a
>>> different price at other stages.
>>
>> Disabling a module is a very explicit operation and there shouldn't be 
>> any
>> manual fixups necessary after (or during) an open commit to please the 
>> ABI
>> checker, IMO. We do have the modules.ignore concept, so why not simply 
>> add a
>> modules.ignore file that lists the module that is removed and make it 
>> part
>> of the remove-module commit? And then make cranky a little smarter to 
>> preserve
>> modules.ignore across opens. So no need to move the open commit (which I
>> personally find very ugly anyways).
>>
>> I'm not cranking kernels that often anymore but how often do you guys 
>> trip
>> over this after closing the release when running test builds? And 
>> isn't the
>> fixup then to drop the module from the ABI list rather than moving the 
>> open
>> commit (and redo the whole thing)?
> 
> I can only speak for myself but I try to always do a
> 
> git log -- debian*/abi
> 
> to see whether some non cranking change meddled with abi. No by moving 
> the open commit before the applied drop commit, git actually changes the 
> following patch to apply to the new files.
> 
> -Stefan

Is the module check even necessary anymore ? The module check was 
implemented back when we still thought a stable ABI was important. Since 
we've abandoned that philosophy some time ago, I see no real benefit to 
the module check. Or rather, I see no benefit to detecting that the 
module list has changed and one has disappeared.

rtg
-- 
-----------
Tim Gardner
Canonical, Inc