linux-kernel - Re: the Linux kernel, testsuites, and maybe *you*

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200709041041.31353.rgetz@blackfin.uclinux.org>
Date:	Tue, 4 Sep 2007 10:41:31 -0400
From:	Robin Getz <rgetz@...ckfin.uclinux.org>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Mike Frysinger" <vapier.adi@...il.com>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: the Linux kernel, testsuites, and maybe *you*

On Sat 1 Sep 2007 18:08, Andi Kleen pondered:
> "Mike Frysinger" <vapier.adi@...il.com> writes:
> 
> > is there any sort of standard for testing and integration into
> > mainline ?  
> 
> Everybody does their own.

That kind of stinks - and seems to be a potential duplication of effort all 
over the place.

> > in the Blackfin world, we've been developing little
> > external kernel modules and adding them to our own testsuite, but
> > often times these things are not Blackfin specific.  case in point,
> > we're integrating a string testsuite to make sure all of the fun str*
> > and mem* functions are sane and operate as they expected, but rather
> > than having just Blackfin benefit here, i'd like to see this pushed
> > upstream ...
> 
> I would like to see this too. I wrote a couple of unit tests
> during x86-64 development too and they would be handy
> to have in a central place.
> 
> The SUSE kernel also has a crasher module that exercises the
> allocators and is pretty useful to stress code in general.
> 
> Disadvantage is that test code tends to be hackish and ugly
> and very specialized and will probably not pass standard review
> procedures.

Then this makes perfect sense to actually have it in the proper places, and 
have it go through the standard review process. I have run into problems 
recently, where ugly hackish tests seem never really catch actual faults. 
(Since they were written by the same person who wrote the driver - Design a 
fault in, code the fault, test the fault is there).

With many eyes - and all that stuff - hopefully we would catch things.

> Also the rt people seem to have pushed a couple of tests in already, 
> but I always hated it that they're in the standard directories.
> RCU also has, in fact they added a "eat all my CPU in tests"
> CONFIG option. Just making that dependent on a CONFIG_UNIT_TESTS
> would be a good change in itself. And then there are the slab
> failure inducers of course.

Putting them close to the standard directories might be OK - keeping the tests 
close to the thing that is being tested may help with maintainers keeping an 
eye on things that might be missed otherwise.

Maybe these types of tests should go into a separate directory - power on self 
tests (post) directories in the respective places? ./kernel/post 
and ./drivers/xxxx/post?

So Mike's proposed string tests would go into ./lib/post/strings.c

When things pass - you get a single indication (all tests for unit X passed) 
or a pass for each test?

-Robin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/