* Kernelnewbies Digest, Vol 49, Issue 7 [not found] <mailman.1.1417626001.14626.kernelnewbies@kernelnewbies.org> @ 2014-12-04 3:21 ` libin 2014-12-04 3:35 ` Saket Sinha 2014-12-04 3:37 ` stability ? libin 1 sibling, 1 reply; 7+ messages in thread From: libin @ 2014-12-04 3:21 UTC (permalink / raw) To: kernelnewbies hello? Does anybody know what test should do before a patch added into the kernel ? I am interested in the method to prove the stability and performance of kernel , especially the stability . can anybody help me ? thanks very much ! icelee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141204/12f1ba52/attachment.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* Kernelnewbies Digest, Vol 49, Issue 7 2014-12-04 3:21 ` Kernelnewbies Digest, Vol 49, Issue 7 libin @ 2014-12-04 3:35 ` Saket Sinha 0 siblings, 0 replies; 7+ messages in thread From: Saket Sinha @ 2014-12-04 3:35 UTC (permalink / raw) To: kernelnewbies Hi icelee, If you want to know what is the correct method to send a patch to kernel mailing list , have a look at this - http://kernelnewbies.org/OPWfirstpatch Regards, Saket Sinha On Thu, Dec 4, 2014 at 8:51 AM, libin <libin@sgepri.sgcc.com.cn> wrote: > hello? > > Does anybody know what test should do before a patch added into the > kernel ? > I am interested in the method to prove the stability and performance of > kernel , especially the stability . > > can anybody help me ? > > thanks very much ! > > > icelee > > > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ^ permalink raw reply [flat|nested] 7+ messages in thread
* stability ? [not found] <mailman.1.1417626001.14626.kernelnewbies@kernelnewbies.org> 2014-12-04 3:21 ` Kernelnewbies Digest, Vol 49, Issue 7 libin @ 2014-12-04 3:37 ` libin 2014-12-04 7:27 ` libin 2014-12-04 15:02 ` Valdis.Kletnieks at vt.edu 1 sibling, 2 replies; 7+ messages in thread From: libin @ 2014-12-04 3:37 UTC (permalink / raw) To: kernelnewbies hello? Does anybody know what test should do before a patch added into the kernel ? I am interested in the method to prove the stability and performance of kernel , especially the stability . can anybody help me ? thanks very much ! icelee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141204/43e4793d/attachment.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* stability ? 2014-12-04 3:37 ` stability ? libin @ 2014-12-04 7:27 ` libin 2014-12-04 10:36 ` Greg Freemyer 2014-12-04 15:02 ` Valdis.Kletnieks at vt.edu 1 sibling, 1 reply; 7+ messages in thread From: libin @ 2014-12-04 7:27 UTC (permalink / raw) To: kernelnewbies I need is what test should do before a new kernel will be released ? Maybe I will modify some kernel codes for some reason , not only the drivers , but I don't know whether it is Stable or not , So I think there should have some standrd tests to run , So I am interestd in how the linux kernel maintainer do as usual ! Regards icelee ???? libin ????? 2014-12-04 11:37 ???? kernelnewbies ??? stability ? hello? Does anybody know what test should do before a patch added into the kernel ? I am interested in the method to prove the stability and performance of kernel , especially the stability . can anybody help me ? thanks very much ! icelee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141204/8b685905/attachment-0001.html ^ permalink raw reply [flat|nested] 7+ messages in thread
* stability ? 2014-12-04 7:27 ` libin @ 2014-12-04 10:36 ` Greg Freemyer 0 siblings, 0 replies; 7+ messages in thread From: Greg Freemyer @ 2014-12-04 10:36 UTC (permalink / raw) To: kernelnewbies On December 4, 2014 2:27:13 AM EST, libin <libin@sgepri.sgcc.com.cn> wrote: > I need is what test should do before a new kernel will be released ? > >Maybe I will modify some kernel codes for some reason , not only the >drivers , but I don't know whether it is Stable or not , > So I think there should have some standrd tests to run , > So I am interestd in how the linux kernel maintainer do as usual ! > I think you fail to understand the complexity of the kernel. There are some overall tests, but in general each subsystem has tests of their own, so your question has no general answer. I follow file systems. The current paradigm is most file systems maintainers are going about the process of ensuring the "xfstests" test suite runs on their file system. Thus more and more, xfstests has become the default stability tester for many/most Linux file systems. I believe the xfs team in particular run that suite for days prior to accepting major code changes. Even more important is that for any bug fix they update xfstests to ensure it finds the bug. That ensures no regressions on that bug in the future. Xfstests has its own mailing list, but I don't recall if is archived anywhere. BOTH Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ^ permalink raw reply [flat|nested] 7+ messages in thread
* stability ? 2014-12-04 3:37 ` stability ? libin 2014-12-04 7:27 ` libin @ 2014-12-04 15:02 ` Valdis.Kletnieks at vt.edu 2014-12-04 16:02 ` nick 1 sibling, 1 reply; 7+ messages in thread From: Valdis.Kletnieks at vt.edu @ 2014-12-04 15:02 UTC (permalink / raw) To: kernelnewbies On Thu, 04 Dec 2014 11:37:45 +0800, libin said: > Does anybody know what test should do before a patch added into the > kernel ? I am interested in the method to prove the stability and performance > of kernel , especially the stability . That will of course be *heavily* dependent on the exact nature of the patch. The Linux kernel is developed with a "lots of small incremental patches" philosophy. As a result, most patches are relatively minor and only require testing that they work - so if it compiles, boots, and you test whatever function the patch does, that's sufficient. Your webcam now outputs RGB like it should, not GBR like it was? Excellent. The ethernet driver no longer crashes when it sees a packet that's exactly 1397 bytes long? Great. Package it up and submit it. If you're adding new functionality, you of course want to test a bit more. Boot the kernel, and let it run for a few days, make sure you don't have any memory leaks or stray pointers or other crashes. That's probably all the testing most patches actually get. And that's OK, most well-written patches don't *need* more testing. If you're ambitious and writing patches that are more invasive, get xfstests and/or the Linux Test Project package and run those against your new kernel. Note that you may need to write new test routines if you added new function. If you're *really* hardcore, get 'trinity' and run that against your kernel. Make sure to back the test system up first, it *can* eat your system. The *real* problem is that the Linux kernel ends up getting used in lots of weird configurations - far too many for any developer to test. And stability issues come in two flavors: Ones that kill your own box in an hour of light use, and ones that only happen on a very small number of systems, none of them yours. I personally manage to trip over 3-4 bugs in linux-next each release cycle, just because I do stuff on my Dell laptop that developers obviously didn't have a way to test. For instance, right now I'm trying to track down a nasty bug in drivers/net/tun.c where it's pretty obvious that the guy who wrote the commit tested what he could (he has a reputation of doing good work), but the Juniper VPN software my employer uses gives it indigestion. Wasn't any way for Herbert to test that one without a Juniper VPN box to test against... Linus had a *long* chase after one bug, that turned out two be two instructions in the wrong order in an asm() statement, which would lead to a system hang if an interrupt came in between the two instructions. So there was a race condition window *literally* 2 cycles wide - and *one* user had a workload that was able to pretty frequently drop an interrupt into that billionth of a second window. Frequent as in "managed that impossible shot several times a day".... And the only real way to find that sort of weirdness is to get the patch into linux-next and then have lots of linux-next testers with different use cases.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 848 bytes Desc: not available Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141204/488f4eac/attachment.bin ^ permalink raw reply [flat|nested] 7+ messages in thread
* stability ? 2014-12-04 15:02 ` Valdis.Kletnieks at vt.edu @ 2014-12-04 16:02 ` nick 0 siblings, 0 replies; 7+ messages in thread From: nick @ 2014-12-04 16:02 UTC (permalink / raw) To: kernelnewbies I agree with Valdis here, unlike user space the kernel has too many weird use cases on different hardware or configs for one developer to test alone. Through Intel does have their test lab for Linux now :). Regards Nick On 2014-12-04 10:02 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 04 Dec 2014 11:37:45 +0800, libin said: >> Does anybody know what test should do before a patch added into the >> kernel ? I am interested in the method to prove the stability and performance >> of kernel , especially the stability . > > That will of course be *heavily* dependent on the exact nature of the > patch. The Linux kernel is developed with a "lots of small incremental > patches" philosophy. As a result, most patches are relatively minor > and only require testing that they work - so if it compiles, boots, and > you test whatever function the patch does, that's sufficient. Your webcam > now outputs RGB like it should, not GBR like it was? Excellent. The ethernet > driver no longer crashes when it sees a packet that's exactly 1397 bytes > long? Great. Package it up and submit it. > > If you're adding new functionality, you of course want to test a bit more. > > Boot the kernel, and let it run for a few days, make sure you don't have > any memory leaks or stray pointers or other crashes. That's probably all > the testing most patches actually get. And that's OK, most well-written > patches don't *need* more testing. > > If you're ambitious and writing patches that are more invasive, get xfstests > and/or the Linux Test Project package and run those against your new kernel. > Note that you may need to write new test routines if you added new function. > > If you're *really* hardcore, get 'trinity' and run that against your kernel. > Make sure to back the test system up first, it *can* eat your system. > > The *real* problem is that the Linux kernel ends up getting used in lots > of weird configurations - far too many for any developer to test. And stability > issues come in two flavors: Ones that kill your own box in an hour of light > use, and ones that only happen on a very small number of systems, none of them > yours. > > I personally manage to trip over 3-4 bugs in linux-next each release cycle, > just because I do stuff on my Dell laptop that developers obviously didn't > have a way to test. For instance, right now I'm trying to track down a > nasty bug in drivers/net/tun.c where it's pretty obvious that the guy who > wrote the commit tested what he could (he has a reputation of doing good > work), but the Juniper VPN software my employer uses gives it indigestion. > Wasn't any way for Herbert to test that one without a Juniper VPN box to > test against... > > Linus had a *long* chase after one bug, that turned out two be two > instructions in the wrong order in an asm() statement, which would lead to > a system hang if an interrupt came in between the two instructions. So > there was a race condition window *literally* 2 cycles wide - and *one* user > had a workload that was able to pretty frequently drop an interrupt into > that billionth of a second window. Frequent as in "managed that impossible > shot several times a day".... > > And the only real way to find that sort of weirdness is to get the patch into > linux-next and then have lots of linux-next testers with different use > cases.... > > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-12-04 16:02 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.1.1417626001.14626.kernelnewbies@kernelnewbies.org>
2014-12-04 3:21 ` Kernelnewbies Digest, Vol 49, Issue 7 libin
2014-12-04 3:35 ` Saket Sinha
2014-12-04 3:37 ` stability ? libin
2014-12-04 7:27 ` libin
2014-12-04 10:36 ` Greg Freemyer
2014-12-04 15:02 ` Valdis.Kletnieks at vt.edu
2014-12-04 16:02 ` nick
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).