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: <4899A931.2020701@s5r6.in-berlin.de>
Date:	Wed, 06 Aug 2008 15:37:53 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Bill Davidsen <davidsen@....com>
CC:	linux-kernel@...r.kernel.org,
	Nick Piggin <nickpiggin@...oo.com.au>,
	jmerkey@...fmountaingroup.com,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Josh Boyer <jwboyer@...il.com>
Subject: Re: [ANNOUNCE] Merkey's Kernel Debugger

Bill Davidsen wrote:
>> Nick Piggin <nickpiggin@...oo.com.au> writes:
>>> and we already have kgdb so you have to also explain why you
>>> can't improve kgdb in the areas it trails mdb.
>>>
>>> But the ideal outcome would be if you could contribute patches to
>>> kgdb to the point where it is as good as mdb. It is already in the
>>
> That idea sounds familiar, the "suspend2" response, when something new 
> and significantly different is offered, instead of putting it in and 
> letting people choose in configuration, take the position that what is 
> there is good enough, and if the author of the new solution will just 
> drop all their ideas and slap some band-aids on the existing code it 
> will be "gooder enough" without actually offering people a choice of 
> something different.

To be fair, choice in "leaf" features like a debugger is not entirely 
comparable to choice in central features.  If the infrastructure does 
not support all use cases reasonably well, its better to fix the 
infrastructure or replace it by a working one, rather than adding a 
second infrastructure which is also not general enough.

In this case:  Make a side-by-side comparison of features and 
shortcomings of the available debuggers (as in Andi's response), then 
decide how the best of both worlds can be achieved + used + maintained 
most easily --- by having both side-by-side, or by taking over some or 
all of one's features into the other.  Either way requires contributors 
to be interested.
-- 
Stefan Richter
-=====-==--- =--- --==-
http://arcgraph.de/sr/
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ