4 ms·

> We were sceptical of that assertion because making the effort to add code to the Linux kernel without planning for it to be used is thoroughly counter-intuiti

> We were sceptical of that assertion because making the effort to add code to the Linux kernel without planning for it to be used is thoroughly counter-intuitive I mean... this seems like a very good point, but from the rest of the article, and the previous one, it sounds like the patch was approved? Why was this allowed into the kernel? looks like drivers/platform/x86/intel/* mostly. Does intel just "own" that section of code? who accepts these patches? I'm not particularly familiar with this stuff so would appreciate someone filling me in on this.

zamadatix 5y ago
> I mean... this seems like a very good point, but from the rest of the article, and the previous one, it sounds like the patch was approved? Intel actually said, in a short snippet where The Register refers to them as "Chipzilla", "If we plan to implement these updates in future products we will provide a deeper explanation of how they are implemented at that time.". One interpretation could be they are saying they haven't figured out if they are going to implement this in anything so they just added it for fun... I'd call that the "makes a good article" interpretation. The other interpretation is they plan to use the feature but have not yet finished planning which products will use it to unlock what and will talk about it in more detailed once planned, I'd call that the "corporatespeak decoded version". If you were a literal interpretation bot I would still say the corporatespeak version fits better than the article filler version hence why the extrapolations with that version don't match up to what is happening. > Why was this allowed into the kernel? looks like drivers/platform/x86/intel/* mostly. Does intel just "own" that section of code? who accepts these patches? I didn't look if it was actually accepted yet or just a proposed patchset but generally Intel will be the maintainers for Intel code (but not always) and they are one of the larger contributors to the kernel overall. You can see more details about maintainers and reviewers (as well as maintainers for sections of code) here https://www.kernel.org/doc/linux/MAINTAINERS#:~:text=One%20job%20the%20maintainers%20(and,feature%20ready%20for%20next%20time https://www.kernel.org/doc/linux/MAINTAINERS#:~:text=One%20j....
- mijoharas 5y ago
  Thanks for that maintainers link. That's exactly what I was looking for. It seems that a lot of the changes in the patchset are in the intel pmt driver, which is maintained by the author of the patch, so that makes sense why the maintainer included it.
Brybry 5y ago
I'm not an expert but: you can look at the log for any given file and see who authored what commit, who reviewed, who actually committed. For example, a different change by the same author [1] And you can search the mailing list[2] by commit hash/author name/etc and look at relevant discussion trees to see lively patch discussion and criticism/final pull requests/etc. I don't believe the changes in question have been merged. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mfd/intel_pmt.c?id=aa47ad3f853ae72c32b7e46dfc8bc2c8dc2dbad7 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [2] https://lore.kernel.org/lkml/?q=David+E.+Box https://lore.kernel.org/lkml/?q=David+E.+Box
sgnnseven 5y ago
I don't think that this is really new for Intel so they are very likely to use this functionality. They've done something similar to Pentiums about 11 years ago: https://www.engadget.com/2010-09-18-intel-wants-to-charge-50-to-unlock-stuff-your-cpu-can-already-d.html https://www.engadget.com/2010-09-18-intel-wants-to-charge-50...

zamadatix 5y ago

> I mean... this seems like a very good point, but from the rest of the article, and the previous one, it sounds like the patch was approved? Intel actually said, in a short snippet where The Register refers to them as "Chipzilla", "If we plan to implement these updates in future products we will provide a deeper explanation of how they are implemented at that time.". One interpretation could be they are saying they haven't figured out if they are going to implement this in anything so they just added it for fun... I'd call that the "makes a good article" interpretation. The other interpretation is they plan to use the feature but have not yet finished planning which products will use it to unlock what and will talk about it in more detailed once planned, I'd call that the "corporatespeak decoded version". If you were a literal interpretation bot I would still say the corporatespeak version fits better than the article filler version hence why the extrapolations with that version don't match up to what is happening. > Why was this allowed into the kernel? looks like drivers/platform/x86/intel/* mostly. Does intel just "own" that section of code? who accepts these patches? I didn't look if it was actually accepted yet or just a proposed patchset but generally Intel will be the maintainers for Intel code (but not always) and they are one of the larger contributors to the kernel overall. You can see more details about maintainers and reviewers (as well as maintainers for sections of code) here https://www.kernel.org/doc/linux/MAINTAINERS#:~:text=One%20job%20the%20maintainers%20(and,feature%20ready%20for%20next%20time https://www.kernel.org/doc/linux/MAINTAINERS#:~:text=One%20j....

mijoharas 5y ago
Thanks for that maintainers link. That's exactly what I was looking for. It seems that a lot of the changes in the patchset are in the intel pmt driver, which is maintained by the author of the patch, so that makes sense why the maintainer included it.

Brybry 5y ago

I'm not an expert but: you can look at the log for any given file and see who authored what commit, who reviewed, who actually committed. For example, a different change by the same author [1] And you can search the mailing list[2] by commit hash/author name/etc and look at relevant discussion trees to see lively patch discussion and criticism/final pull requests/etc. I don't believe the changes in question have been merged. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mfd/intel_pmt.c?id=aa47ad3f853ae72c32b7e46dfc8bc2c8dc2dbad7 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [2] https://lore.kernel.org/lkml/?q=David+E.+Box https://lore.kernel.org/lkml/?q=David+E.+Box

sgnnseven 5y ago

I don't think that this is really new for Intel so they are very likely to use this functionality. They've done something similar to Pentiums about 11 years ago: https://www.engadget.com/2010-09-18-intel-wants-to-charge-50-to-unlock-stuff-your-cpu-can-already-d.html https://www.engadget.com/2010-09-18-intel-wants-to-charge-50...