On 05.07.2017 16:33, Steven Rostedt wrote: > On Wed, 5 Jul 2017 16:06:07 +0200 > Greg KH <greg@xxxxxxxxx> wrote: > [...] >> I don't mean to poo-poo the idea, but please realize that around 75% of >> the kernel is hardware/arch support, so that means that 75% of the >> changes/fixes deal with hardware things (yes, change is in direct >> correlation to size of the codebase in the tree, strange but true). > I would say that if it's for a specific hardware, then it's really up > to the maintainer if there should be a test or not. As a lot of these > is just to deal with some quirk or non standard that the hardware does. > But are these regressions, or just some feature that's been broken on > that hardware since its conception? > > That is, Thorsten this is more for you, how much real regressions are in > hardware? [...] >From this and other mails in this thread I got the impression some more data would be helpful -- for example a few percentage numbers on * how many of the regressions are in hardware-specific/driver code * how many regressions suddenly pop up due to a unrelated (and maybe even correct) change * for how many regressions does it make sense to write a selftest to catch similar issues beforehand in the future. I'll try to gather some of those numbers when doing regression tracking for 4.13 (sorry again that I had to skip 4.12), so be prepare yourself for a mail when you include a "Fixes:" tag in a commit ;-) Then there is some data to talk about on the summit or continue the discussion on this mailing list or LKML. BTW, Steven, you in this thread wrote "discuss if we want to consolidate the format of all the kselftests and have something that everyone (or most) developers agree on". I put that in my notes and try to make sure we do not forget about this. Or is this something you'll drive forward yourself? Ciao, Thorsten P.S.: Sorry, I'm a bit late with my reply here. My real job (which is not really about kernel work) and some other things required my attention in the past few days... -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
