On 10/07/2016 08:26 AM, Greg KH wrote: > On Fri, Oct 07, 2016 at 08:05:59AM -0700, Thomas Hellstrom wrote: >> On 10/07/2016 07:18 AM, Greg KH wrote: >>> On Fri, Oct 07, 2016 at 06:47:47AM -0700, Thomas Hellstrom wrote: >>>> On 10/07/2016 05:48 AM, Greg KH wrote: >>>>> On Thu, Oct 06, 2016 at 09:51:08PM -0700, Thomas Hellstrom wrote: >>>>>> On 10/06/2016 09:22 PM, Greg KH wrote: >>>>>>> On Thu, Oct 06, 2016 at 09:19:50PM -0700, Thomas Hellstrom wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> On 10/06/2016 08:52 PM, Greg KH wrote: >>>>>>>>> On Thu, Oct 06, 2016 at 06:54:43PM -0700, Thomas Hellstrom wrote: >>>>>>>>>> Hi, Stable! >>>>>>>>>> >>>>>>>>>> As you might be aware of, some companies that maintain linux kernel >>>>>>>>>> drivers have the habit of assigning each driver change a new version >>>>>>>>>> number. >>>>>>>>> And, as you have found out, that's a horrible thing to do for Linux and >>>>>>>>> doesn't work at all :) >>>>>>>>> >>>>>>>>> Just because it works for other slower-moving operating systems, I >>>>>>>>> wouldn't recommend doing it for Linux. >>>>>>>> Yes, I'm fully aware of the difficulties, though I was hoping that I, >>>>>>>> with the help some bright ideas from the list could come up with a >>>>>>>> clever way to make everybody happy. >>>>>>> But who has the problem here really? Not the kernel community or >>>>>>> developers, but rather an odd set of unskilled QA people (your word, not >>>>>>> mine.) >>>>>>> >>>>>>> Why can't they get more "skill"? :) >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> greg k-h >>>>>> Well, I would in no way call our QA people unskilled just because they >>>>>> in general don't have the skill to know how to locate a particular, >>>>>> sometimes well-hidden git repo and find out if a certain bug is fixed or >>>>>> not. Not even Einstein knew how to do that ;) >>>>> Huh? All of the kernel trees we "release" are in one single repo, and >>>>> it is very well known (linked to off of the kernel.org site front page): >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_cgit_linux_kernel_git_stable_linux-2Dstable.git&d=CwIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=2nFSKLtpsbVgl3FEz2G3Io4y14rAxcjmJACORglPiwI&s=E02w2V0waHQkqaQ4KAcPYM3o2nWfYavhd12uJDJ24dI&e= >>>>> >>>>> How is that difficult to find? >>>> The "vanilla" stable ones are easy. The distro ones may not be, save >>>> Ubuntu that sometimes "take over" a stable tree. Typically the kernels >>>> we test are a distro-modified version of a stable tree. >>> Then go complain to the distros! And even then, all of them keep their >>> kernels in pretty well-known, and documented, locations. If not, go bug >>> them, there is nothing we can do about it. >>> >>> Also, shouldn't your QA scripts just suck in the correct distro >>> kernel/tree automatically? No QA person should have to ever hunt for a >>> kernel tree, that means you have not automated it, which seems very >>> wrong to me. >>> >>>>>> But I won't try to argue here. I do think, though, that as long as >>>>>> people believe the easier solution is to version each change they will >>>>>> keep on doing that and unfortunately as a result important patches won't >>>>>> get CC'd stable because that would mess up the versioning. >>>>>> >>>>>> From your answer I take it there is no interest from the stable >>>>>> maintainers in helping solving this using some kind of mainline hash >>>>>> registering tool. I guess perhaps another option is to locally automate >>>>>> stable / distro git tree scanning. >>>>> Maybe I really don't understand the "issue" you are trying to address >>>>> here, can you try to rephrase it by showing a real example of what you >>>>> are trying to solve? >>>>> >>>>> But again, there's nothing we can do about out-of-tree code, remember, >>>>> they know where we are (and I'll take anything!), but we don't know >>>>> where they are... >>>>> >>>>> thanks, >>>>> >>>>> greg k-h >>>> Yes. The problem would be >>>> >>>> Given a *binary* version of distro kernel X, based on stable kernel Y. >>>> What _upstreamed_ bugfix patches has touched our module since the stable >>>> branch was created? Let's assume the distro git tree is hard to find. >>>> >>>> a) Now if stable maintainers and distro kernel maintainers could use a >>>> flag "record commit id" to the git am command, the mainline commit id >>>> would be added to a binary visible table in the module, problem solved. >>> But the stable mantainers DO all do that already today! That info is >>> all there, and has been there, for over a decade! Just look at every >>> commit in the stable kernel branches, it has that information for you, >>> in a semi-easy format to parse. >> 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.. > > Oh wait, look, we already do that with the git commit id as part of the > version number, you always know exactly what is contained in that binary > based on that. > > So again, the community has already done this for you, I don't know why > you are ignoring it :( > > And again, if you have problems with distro source trees, go complain to > them. Yes, there are some distro developers on this list, but it's not > a distro-specific place to complain to them about things, you know > better than that... > > thanks, > > greg k-h So the intention was never to complain but to look for input and comments, and I think I got it. 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