On Wed, 2020-07-01 at 11:07 -0500, Michael Catanzaro wrote:
> So the last two times thermald was proposed (first as a F32 change 
> proposal, then more recently to the Workstation WG) it was rejected on 
> the grounds that it was not useful without dptfxtract installed. Now 
> it's clear that everybody was mistaken about that, so seems it makes 
> sense to reconsider.
> I have a couple questions. First, why is thermal management occurring 
> in userspace? Can you please provide a technical explanation as to why 
> the kernel is not the right place for this code?

The thermal daemon has a bit of information:

It lists the following reasons:
 * A short time to market
 * Proactively controlled temperature
 * Use of existing kernel infrastructure
 * A defined architecture, which can be easily enhanced.

In general, I don't see a problem with moving some logic into
userspace. It is not like the kernel is in a much better position to
make decisions. It only is closer to the hardware from an architectural
point of view and will only be in a better position if decisions must
not be delayed (e.g. protecting the hardware from overheating).

On Wed, Jul 1, 2020 at 11:53 am, Richard W.M. Jones <rjo...@redhat.com> 
> wrote:
> > Is there some background about why dptfxtract is proprietary?  (I see
> > that it's a program provided by Intel.)  Is it just because no one's
> > done the work to make a free equivalent or does it require some
> > secret/patented/whatever knowledge to work?
> I'm also interested in this question. In particular, since thermald and 
> dptfxtract are both the same upstream, it seems really hostile to the 
> open source community for thermald to perform better if you have this 
> extra proprietary portion of the project installed.

My interpretation is that, Intel is trying to protect their IP around
thermal management and how DPTF works in particular.

So, for me, the hostile part here is that we are dealing with a
hardware platform that contains components for which the manufacturer
is not willing to provide proper documentation.

The thermald upstream on the other hand is trying to provide the best
possible experience while working under these imposed constraints. So
thermald will use all the information that it can get, and dptfxtract
allows exporting proprietary information encoded in the DPTF related
data stored in ACPI.


Attachment: signature.asc
Description: This is a digitally signed message part

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to