Req: thermald special case

[Timo Aaltonen]

Hi,

Thanks for looking into this,

Robie Basak kirjoitti 19.10.2022 klo 19.55:
> On Tue, Oct 11, 2022 at 09:58:36AM +0300, Timo Aaltonen wrote:
>> Christopher James Halse Rogers kirjoitti 28.9.2022 klo 10.07:
>>> It's not entirely clear to me what you want to do here.
>>>
>>> If you need to fix some bugs in Jammy, and updating to thermald 2.5.0 is
>>> basically the same as applying all the patches you'd need, then you can
>>> just upload 2.5.0 and justify it in the SRU bug.
> 
>> I've uploaded a backported thermald to jammy queue, anyone willing to have a
>> look? Focal is next once this is accepted.
> 
> This upload seems to contain various changes that aren't covered by SRU
> bugs - for example to consider the risk of regression in changing that
> code, or how you plan to test those fixes. So I don't think this fits
> the conditions that Christopher noted above.
 >
> If you want to update thermald with a major version bump on the basis of
> hardware enablement for new hardware, then that would be justifiable as
> an SRU under existing policy, but we need to ensure that we do not
> regress existing hardware or functionality.
> 
> https://wiki.ubuntu.com/StableReleaseUpdates/thermald provides some
> justification there, but I don't think it's complete. For example, is it
> possible that users are using thermald on hardware not covered by
> upstream tests? By "all the unit tests must pass in all the supported
> Intel CPUs", who defines "supported"? Is it possible that Ubuntu users
> have hardware not covered by that definition of "supported"? Is there
> any risk to users of non-Intel hardware? How complete is upstream's test
> coverage? What assurance is there that there will be no feature
> regressions?
> 
> For example, take the following upstream commit, which I think is being
> included in this proposed SRU:
> 
> https://github.com/intel/thermal_daemon/commit/7e490fc79d784b3faf8314af98ec14981ba7fb75
> 
> If this code path was being used previously, I think that would be a
> functional regression. 1) Is this safe in relation to Ubuntu kernel
> versions? 2) Did this actually get checked before upload? 3) What in
> your proposed QA process would catch this kind of change to ensure that
> the specific requirements for each such deprecation is met in Ubuntu
> stable releases?
I'll let Koba comment on the other points, but the sysfs interface has 
been in the kernel since 5.3:

commit fdf4f2fb8e8990c131b2b1a5a9c03681bb16e87a
Author: Srinivas Pandruvada <srinivas.pandruvada at linux.intel.com>
Date:   Mon Jul 22 18:03:02 2019 -0700

     drivers: thermal: processor_thermal_device: Export sysfs interface 
for TCC offset


so a backport to focal (which is planned) should be safe in that regard.


-- 
t