Is the Kernel Janitors project still alive?
I have been poking around on the Kernel Newbies site and there are listings about the old Kernel Janitors project but everything seems out of date in addition to various versions/homes of the Kernel Janitors project floating around at various URLs. Is there some live version of this project somewhere or has there been a replacement? A unified list of needed but non-critical clean-ups? Or, is it suggested people just look at bug reports? sincerely, Christopher
On Thu, 18 Jul 2013 08:33:05 -0500, Christopher Stanton said:
Is there some live version of this project somewhere or has there been a replacement? A unified list of needed but non-critical clean-ups? Or, is it suggested people just look at bug reports?
Janitors is pretty much deceased, for several reasons: 1) Most of the low-hanging fruit that can be done by somebody who's just starting out has already been done. The kernel tree is much cleaner than it was when the Janitors project started. 2) There's fewer old APIs to clean up, as most subsystem maintainers require that a patch series that replaces an API also clean up the old one. 3) For many subsystems, the maintainer will give some pushback for style cleanup patches not part of actual development, for two reasons: (a) it's possible for a cleanup patch to break something (for instance, a bad cleanup of curly brackets can change the control flow). So they don't like patches against old stable code that could destabilize it. (b) If there *is* other development going on, style cleanups cause merge conflicts (unless they're done as Step 0 of a development patch, by the guy writing the code, so all the conflicts are pre-resolved). A good place to start is to just use git to suck down the current linux-next tree, build it, run it, and report all problems you encounter. Most code only gets tested on the 3-4 boxes the code author has access to before it gets into the linux-next tree. I usually manage to trip over anywhere from 1 to 5 bugs per kernel release, just because nobody else has actually tried running the code on a Dell Latitude with the same .config as I have and the same workflow. If anything, we need a good pool of kernel testers even more than we need more kernel coders. (And you'll learn a ton that way too - some 95% of what I know about kernel innards has come from "Oh crud, what did I break *this* time?" investigation...
On Thu, Jul 18, 2013 at 1:26 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 18 Jul 2013 08:33:05 -0500, Christopher Stanton said:
Is there some live version of this project somewhere or has there been a replacement? A unified list of needed but non-critical clean-ups? Or, is it suggested people just look at bug reports?
Janitors is pretty much deceased, for several reasons:
What's the status of "The Linux Driver Project" http://www.linuxdriverproject.org/mediawiki/index.php/Main_Page If it's still active, it has a list of devices in need of drivers to be written. Also, I should add the Kingwin USI-2535U3 USB3 / Sata adapter I bought a few months ago. http://www.ramplus.com/uskiusb30tos.html I asked about how to troubleshoot it's lack of functionality back in Feb. No one offered advice, so I forgot about it but I really would like to have it usable. Would have saved me a few minutes of disassembling a drive enclosure just yesterday. (I could have left the drive in its enclosure and used the adapter to connect to my laptop. It's nice and small so I could carry 2 or 3 of those in my laptop bag and be able to talk to multiple bare SATA drives with the gear in my bag! It's relatively cheap (less than $50 for sure). I'll buy someone one if they will get it working with the vanilla linux kernel. Greg
On Jul 18 2013, Valdis.Kletnieks@vt.edu wrote: [snip, snip, snip]
A good place to start is to just use git to suck down the current linux-next tree, build it, run it, and report all problems you encounter. Most code only gets tested on the 3-4 boxes the code author has access to before it gets into the linux-next tree. I usually manage to trip over anywhere from 1 to 5 bugs per kernel release, just because nobody else has actually tried running the code on a Dell Latitude with the same .config as I have and the same workflow.
One of the things I really miss in the open source kernel world (coming from the commercial world) is the lack of test packages that everyone automatically runs, just in case they broke something. FreeBSD had nothing, AFAICT, with occassional painful results. Does the linux kernel have any kind of regression test package? If so, where can I find it? If not, does anyone know of ongoing attempts to create one? A quick web search gave me a few pointers to attempts at this: pdf about a regression test framework: https://www.kernel.org/doc/ols/2007/ols2007v2-pages-285-296.pdf A project called crackerjack: http://sourceforge.net/projects/crackerjack/ A paper from a 2008 linux symposium: http://ols.fedoraproject.org/OLS/Reprints-2008/babulal-reprint.pdf What I don't see is any kind of definitive answer - as in, "just clone this git repo and build/run it". And the bug reports I see discussed tend to come from people trying to use linux to accomplish real work. So is there something current, live, and useful?
If anything, we need a good pool of kernel testers even more than we need more kernel coders. (And you'll learn a ton that way too - some 95% of what I know about kernel innards has come from "Oh crud, what did I break *this* time?" investigation...
-- Arlie Arlie Stephens arlie@worldash.org
On Thu, 18 Jul 2013 10:58:36 -0700, Arlie Stephens said:
Does the linux kernel have any kind of regression test package? If so, where can I find it? If not, does anyone know of ongoing attempts to create one?
A quick web search gave me a few pointers to attempts at this:
The Google-foo is weak in this one. :) You missed the biggest one of all: The Linux Test Project: http://ltp.sourceforge.net/ Enjoy. If this doesn't address your needs, feel free to contribute to it until it does. :)
On Jul 18 2013, Valdis.Kletnieks@vt.edu wrote:
On Thu, 18 Jul 2013 10:58:36 -0700, Arlie Stephens said:
Does the linux kernel have any kind of regression test package? If so, where can I find it? If not, does anyone know of ongoing attempts to create one?
A quick web search gave me a few pointers to attempts at this:
The Google-foo is weak in this one. :) You missed the biggest one of all:
Too true. One of the little known secrets of working with linux is that the web is generally the best way to learn things - not the source code. This is messing with my head ;-) but at least I'm getting much better at finding things then when I started. I am, however, still only an egg (at searching).
The Linux Test Project: http://ltp.sourceforge.net/
Enjoy. If this doesn't address your needs, feel free to contribute to it until it does. :)
This looks great. Thank you. And quite seriously, I suspect that test development is a great way to learn - doubly so if you then turn around and fix the bugs your tests uncover. And I've never yet seen a project where the tests weren't suffering from bitrot or worse, so there's sure to be work to be done. -- Arlie
One of the things I really miss in the open source kernel world (coming from the commercial world) is the lack of test packages that everyone automatically runs, just in case they broke something. FreeBSD had nothing, AFAICT, with occassional painful results.
Does the linux kernel have any kind of regression test package? If so, where can I find it? If not, does anyone know of ongoing attempts to create one?
A quick web search gave me a few pointers to attempts at this:
pdf about a regression test framework: https://www.kernel.org/doc/ols/2007/ols2007v2-pages-285-296.pdf
A project called crackerjack: http://sourceforge.net/projects/crackerjack/
A paper from a 2008 linux symposium:
http://ols.fedoraproject.org/OLS/Reprints-2008/babulal-reprint.pdf
That 2008 paper points to the LTP suite whose website implies they produced a May 2013 stable, so it's definitely ongoing. Here's the how to: http://ltp.sourceforge.net/documentation/how-to/ltp.php#_3
On Thu, Jul 18, 2013 at 1:58 PM, Arlie Stephens <arlie@worldash.org> wrote:
On Jul 18 2013, Valdis.Kletnieks@vt.edu wrote: [snip, snip, snip]
A good place to start is to just use git to suck down the current linux-next tree, build it, run it, and report all problems you encounter. Most code only gets tested on the 3-4 boxes the code author has access to before it gets into the linux-next tree. I usually manage to trip over anywhere from 1 to 5 bugs per kernel release, just because nobody else has actually tried running the code on a Dell Latitude with the same .config as I have and the same workflow.
One of the things I really miss in the open source kernel world (coming from the commercial world) is the lack of test packages that everyone automatically runs, just in case they broke something. FreeBSD had nothing, AFAICT, with occassional painful results.
Does the linux kernel have any kind of regression test package? If so, where can I find it? If not, does anyone know of ongoing attempts to create one?
A quick web search gave me a few pointers to attempts at this:
pdf about a regression test framework: https://www.kernel.org/doc/ols/2007/ols2007v2-pages-285-296.pdf
A project called crackerjack: http://sourceforge.net/projects/crackerjack/
A paper from a 2008 linux symposium:
http://ols.fedoraproject.org/OLS/Reprints-2008/babulal-reprint.pdf
What I don't see is any kind of definitive answer - as in, "just clone this git repo and build/run it". And the bug reports I see discussed tend to come from people trying to use linux to accomplish real work.
So is there something current, live, and useful?
For filesystems, the xfstests package is heavily used and has over 200 separate test modules. The name "xfs" is due to its heritage a decade or more ago. It now has extensive support for other filesystems including ext4 and btrfs in particular. ie. There are generic tests that all filesystems should pass and there are unique tests that target xfs OR ext4 OR btrfs (and possibly others). I know the xfs and ext4 maintainers run extended xfstest runs prior to merging major changes. Further when a new bug is reported, they often implement a new xfstest module to catch it as part of the bug fix process. That ensures that bug won't be coming back in the future. In general xfstests is not a performance suite, it just tests for functionality. Also, xfstests has been under aggressive revision for at least the last couple years, so it is definitely maintained. For block level testing as a whole, including performance, Jens Axboe supports fio. I think a lot of fio users actually test their overall storage stack, not just one aspect. For developers, by keeping the stack constant other than the one component which is under test you can evaluate if the change helped or hurt. Greg
participants (5)
-
Arlie Stephens -
Christopher Stanton -
Greg Freemyer -
Philip Whitehouse -
Valdis.Kletnieks＠vt.edu