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: https://01.org/linux-thermal-daemon/documentation/introduction-thermal-daemon 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 <rjones@xxxxxxxxxx> > 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. Benjamin
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
