On Fri, 2008-01-18 at 00:47 -0800, Andrew Morton wrote: > On Fri, 18 Jan 2008 09:36:10 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote: > > > > > * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > > > > > Probably it would be more efficient to have the people who wrote the > > > > code also test it. > > > > > > Well, that would certainly help. > > > > > > I do test all of my patches and generally all of the patches I sign > > > off, but surely that's not enough. > > > > please add a .config option dependent on CONFIG_DEBUG_KERNEL=y [and > > default-disabled] that auto-tests suspend/resume functionality 60 > > seconds after hitting user-space (the suspend/resume cycle kept small > > via a small RTC timeout) and s2ram correctness will be tested _a lot_ > > more. > > > > (it doesnt matter if graphics does not resume fine - at least for my > > tests) > > > > kprobes had similar problems and it now has a few simple smoke-tests - > > which i just saw trigger on a patch that i did not notice would break > > kprobes. I think this should be done for all functionality that is not > > regularly triggered by a normal distro bootup (and which is easy to > > overlook in testing). > > > > Seeing as we're so lame about being able to distribute userspace stuff: > create a shell script in /proc/rc.kernel and start teaching initscripts to > run it. Then we can modify it at will. > > I hate me.
With all the discussion lately about boot-time smoketests and self-tests maybe this kind of stuff would be a good first candidate for useful new early-userspace functionality. Then the kernel build could be taught about building an initramfs that runs a bunch of tests and leaves the user in a shell letting them know if it passed or not. This would be a great way for increasing the number of testers, just ask them to build with that option and a _known_ testsuite could be reported as working or not. Or maybe I'm out to lunch.... Harvey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/