Is the Kernel Janitors project still alive?

Is the Kernel Janitors project still alive?

[Christopher Stanton]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130718/0618d825/attachment-0001.html 

Is the Kernel Janitors project still alive?

[Valdis.Kletnieks at vt.edu]

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...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130718/435e9f67/attachment.bin 

Is the Kernel Janitors project still alive?

[Greg Freemyer]

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

Kernel Testing (was Re: Is the Kernel Janitors project still alive?)

[Arlie Stephens]

On Jul 18 2013, Valdis.Kletnieks at 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 at worldash.org

Kernel Testing (was Re: Is the Kernel Janitors project still alive?)

[Valdis.Kletnieks at vt.edu]

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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130718/63f627fe/attachment.bin 

Kernel Testing (was Re: Is the Kernel Janitors project still alive?)

[Philip Whitehouse]

> 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

Kernel Testing (was Re: Is the Kernel Janitors project still alive?)

[Arlie Stephens]

On Jul 18 2013, Valdis.Kletnieks at 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

Kernel Testing (was Re: Is the Kernel Janitors project still alive?)

[Greg Freemyer]

On Thu, Jul 18, 2013 at 1:58 PM, Arlie Stephens <arlie@worldash.org> wrote:
> On Jul 18 2013, Valdis.Kletnieks at 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