From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2985 invoked by alias); 19 Nov 2004 05:05:20 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2641 invoked from network); 19 Nov 2004 05:04:43 -0000 Received: from unknown (HELO demos.bsdclusters.com) (69.55.225.36) by sourceware.org with SMTP; 19 Nov 2004 05:04:43 -0000 Received: from demos.bsdclusters.com (demos [69.55.225.36]) by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id iAJ54en1078256; Thu, 18 Nov 2004 21:04:40 -0800 (PST) (envelope-from kmacy@eventdriven.org) Received: from localhost (kmacy@localhost) by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id iAJ54dlc078253; Thu, 18 Nov 2004 21:04:39 -0800 (PST) X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs Date: Fri, 19 Nov 2004 07:19:00 -0000 From: Kip Macy X-X-Sender: kmacy@demos.bsdclusters.com To: Ian Lance Taylor cc: Andrew Cagney , gdb@sources.redhat.com Subject: Re: GDB is the GNU project's native debugger In-Reply-To: Message-ID: <20041118204120.O67410@demos.bsdclusters.com> References: <419A2E2F.5010602@gnu.org> <419A9BBE.6010000@gnu.org> <419BAB0C.2000607@gnu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-11/txt/msg00195.txt.bz2 I personally do not feel as strongly motivated by the GPL as many who have or have at least tried to contribute to GNU software. However, I also do not sympathize with those who strongly object to the GPL because of the limitations it sometimes places on business use. It is the right of those who have done the bulk of the work on a piece of software to license it as they see fit. Thus I feel that I am fairly neutral in this discussion. One possible approach to discussing the difficult tradeoffs involved is to take a page from legal discourse. Rather than speaking in terms of "principles", talk about acceptance "criteria". To make their application clear, you could create the moral equivalent of case law. Create a document where you describe past issues such as async native, frame handling, or architecture interface change, what the perceived trade-offs were and why you made the decision that you did. This document would be much more useful than wading through mail archives, and it would make it easier, assuming you are self-consistent, to justify future decisions. -Kip On Thu, 18 Nov 2004, Ian Lance Taylor wrote: > Andrew Cagney writes: > > > > It's a complex problem and as such has middle ground and negotiation > > dependant on the scale of the work: > > > > - Corinna recently changed an architecture interface and, since it was > > straight forward, did the 'busywork'. > > > > - The frame code, on the other hand, was anything but straight > > forward, it instead started with a single architecture and then > > expanded as back end maintainers did their (much appreciated) stuff. > > In the end though, a long list of architectures were simply deleted > > (should I have instead done the 'busywork' of frameifying the ns32k?). > > > > Perhaps you can expand on your point by explaining where you would > > strike up the balance for making an invasive change such as > > asynchronous native (proc, ptrace) support. GDB has many many > > non-async embedded targets, but only two natives. Should we predicate > > the work on the modification of all the embedded inferiors? Or should > > we accept that the work is so key to GDB's future as a native that we > > can tolerate a few short term problems? > > I think that in general you expanded on my point better than I could. > As you say, it's a complex problem. You are proposing a simple > principle, and my concern is that once such a thing is adopted it will > be used to enforce simplistic solutions to complex problems. As I > said before, the principle itself seems unobjectionable in many > contexts. My concern is that it will be applied in cases where it is > too simple. > > Or, to put it another way: why do we need an overly simple statement > about what we agree is a complex issue? > > On your specific issue, I think that async native support would > require either a flag day or supporting two separate interfaces for > some time. A flag day is only acceptable if all major architectures > can be converted simultaneously. Off the cuff I would say that > supporting two separate interfaces would have to last for at least a > year. Yes, this is hard. Yes, it leads to more duplicated work. A > clean and elegant program is a goal, but it is not the only goal. > > > What I do see is continuing pressure and lobying, some times comming > > from the most ironic of quarters :-) > > Well, you can make the lobbying public, or, since of course that may > not be possible, you can ask for our input in an indirect fashion. > I'm replying to the indirect query. Naturally I don't have all the > information which you have. > > > Anyway, would it be useful if the process, as you describe it, was > > explicitly documented? > > I'm not sure it makes much difference, myself. But on that question I > may be too far on the inside, even though not a serious gdb developer. > Perhaps for others with less historical knowledge, more documentation > would be helpful. > > Ian >