On 10/07/2016 10:13 AM, Greg KH wrote: > On Fri, Oct 07, 2016 at 08:45:28AM -0700, Thomas Hellstrom wrote: >>>> Indeed they do, but the idea here was to have that information >>>> extractable from a binary, but that would have required cooperation both >>>> from the stable maintainers and the distro maintainers (who typically >>>> are on this list). That's why I posted. >>> You can't extract each individual patch information from a binary, how >>> would you encode 10k patches in every release? >> Well, that wasn't the idea. The idea was to have the id's of the >> *stable* backports >> encoded automatically *only* for those modules that requested it. >> However, I realize that such a thing could easily grow.. > So, you want to see the 8-10 patches we add every single day to the tree > somehow? For the 4.4.y kernel right now that would be 2753 patches. Do > you want to waste that much memory for something that the source tree > provides for you today already, automatically in a provable way? > > I really don't think you want this. Understood. Point taken. > > What vendor kernels are you having problems with, and why isn't your QA > scripts already set up to automatically pull from them with every push > they do? I know a number of good vendors also provide build systems, > for free, that do this work for you, whenever the base repo changes. > Why aren't you using them today already for your kernel modules? > > And again, the question you don't seem to ever answer, what kernel > modules are you needing this work for? Why aren't they upstream? What > is preventing that from happening? Is it a failure somehow on our > development process? > > thanks, > > greg k-h So my end goal here is to find a way for the vmware paravirtual in-tree kernel modules to stop bumping version numbers on each commit / commit series and start pushing important bugfixes to stable, while making kernel maintainers happy and company people happy. There are no out-of-tree modules whatsoever involved in this discussion. It's totally clear to me at this point that binary commit information is not the way to go, and that we have to evaluate other ways, perhaps some of which you are suggesting above. Thanks Thomas -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html