Re: echo mem > /sys/power/state

On Fri, 2008-01-18 at 00:47 -0800, Andrew Morton wrote:
On Fri, 18 Jan 2008 09:36:10 +0100 Ingo Molnar <mingo@xxxxxxx> wrote:


* Rafael J. Wysocki <rjw@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • [-mm][PATCH 0/6] (yet another) kprobes x86 code unification and boosters
    ... I developed a series of patches which unifies kprobes code on x86 ... These patches can be applied to 2.6.24-rc4-mm1. ... Software Solutions Division ...
    (Linux-Kernel)
  • Re: echo mem > /sys/power/state
    ... I do test all of my patches and generally all of the patches I sign ... (it doesnt matter if graphics does not resume fine - at least for my ... kprobes had similar problems and it now has a few simple smoke-tests - ...
    (Linux-Kernel)
  • Re: echo mem > /sys/power/state
    ... I do test all of my patches and generally all of the patches I sign ... (it doesnt matter if graphics does not resume fine - at least for my ... kprobes had similar problems and it now has a few simple smoke-tests - ...
    (Linux-Kernel)
  • [patch 0/4] Kprobes support for IA64
    ... Attached patches following this mail are a port of Kprobes and Jprobes for IA64. ...
    (Linux-Kernel)
  • Re: command line vs grid control
    ... You can't write a shell script to check metalink for patches. ... @home.com is bogus. ...
    (comp.databases.oracle.server)