linux-kernel - Re: [patch] suspend/resume self-test

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] [day] [month] [year] [list]

Message-ID: <20080220101542.GC3881@elte.hu>
Date:	Wed, 20 Feb 2008 11:15:42 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	David Brownell <david-b@...bell.net>
Cc:	Pavel Machek <pavel@....cz>, rjw@...k.pl,
	linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch] suspend/resume self-test

* David Brownell <david-b@...bell.net> wrote:

> > nowhere did i suggest that it should be default-enabled ...
> 
> The patch you asked to be merged *DID* have it be default-enabled! So 
> you did more than just "suggest"... if that option is enabled in 
> Kconfig, this test is always forced on and it will cause failures on 
> systems where STR has never worked.

i think you dont understand what "default enabled" means in this 
context. Default enabled means the Kconfig entry has a "default y" line 
- which it did not have in the patch i sent.

if a tester enables the .config option then it is very much expected to 
be triggered, just like the other .config debug options. Of course, the 
tester specifically enabled it, so that's what we want to happen. Not 
some other "yes_i_really_meant_it" boot option ... There can also be 
_another_ .config option that turns off the 'run by default' property - 
but if someone selects the _default off_ feature and enables it, just 
like i did, then the feature is very much expected to run.

you really seem to have deep misunderstandings about how testers use 
Linux, what it takes to build up a proper debug infrastructure and how 
to utilize all these things to make Linux better. You come from the 
embedded world where everything is configured together specifically, 
where people know what they are using and were every feature is well 
accounted for. But you seem to have little insight into how 
distributions utilize kernel features and what it takes to accept the 
help of testers who dont know the field that well but still want to help 
out - as long as we let them.

These are well-established practices we use in all other debug features 
that help Linux today, and what you are asking for is weird, unusual and 
wrong. Please take a look at how all the other debug stuff works. Rule
#1: testers dont have to beg the kernel for 1 hour and have to write 2
patches to let the test code be run finally ... ;-) This isnt even about 
any nuances where reasonable people might disagree, this is really basic 
testing-101 stuff.

	Ingo
--
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/