netdev - Re: [BUG] New Kernel Bugs

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: <20071113183605.GG4250@stusta.de>
Date:	Tue, 13 Nov 2007 19:36:05 +0100
From:	Adrian Bunk <bunk@...nel.org>
To:	Mark Lord <liml@....ca>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>, protasnb@...il.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	alsa-devel@...a-project.org, linux-ide@...r.kernel.org,
	linux-pcmcia@...ts.infradead.org,
	linux-input@...ey.karlin.mff.cuni.cz,
	bugme-daemon@...zilla.kernel.org
Subject: Re: [BUG] New Kernel Bugs

On Tue, Nov 13, 2007 at 01:18:43PM -0500, Mark Lord wrote:
> Adrian Bunk wrote:
>> On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote:
>>> Ingo Molnar wrote:
>>>> for example git-bisect was godsent. I remember that years ago bisection 
>>>> of a bug was a very laborous task so that it was only used as a final, 
>>>> last-ditch approach for really nasty bugs. Today we can autonomouly 
>>>> bisect build bugs via a simple shell command around "git-bisect run", 
>>>> without any human interaction! This freed up testing resources 
>>> ..
>>>
>>> It's only a godsend for the few people who happen to be kernel developers
>>
>> It's also godsend for users who want a regression they observe fixed.
>>
>> If you can tell which patch broke it you often turned a very hard to debug 
>> problem into a relatively easy fixable problem.
> ..
>
> Oh yes, definitely.  When that use happens to be a kernel dev + git user,
> it saves the *fool who broke it* a hell of a lot of time, because they can
> slough it off onto the poor bloke who notices it.

"fool who broke it" are hard works. Bugs are part of software 
development, so you'd have to name everyone who develops software
a fool.

But the main point is that often you don't know who broke it until you 
know which commit broke it.

> Mind you, no arguing that this is effective when that poor bloke
> has a day free to download the git-tree and build/reboot a dozen times.

I did bisecting myself, and I know that it costs time and work.

But the first point is the above one that it makes otherwise nearly 
undebuggable problems debuggable and fixable.

Another point is that it shifts the work from the few experienced 
developers to the many users. Users (and voluntary testers) we have
many, but developer time for debugging bug reports is a quite scarce 
resource.

And why "poor bloke"? Bisecting takes time, but that's not different 
from e.g. writing code or cleaning up code or going through bug reports.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html