From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9488 invoked by alias); 2 Dec 2005 22:12:50 -0000 Received: (qmail 9476 invoked by uid 22791); 2 Dec 2005 22:12:49 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 02 Dec 2005 22:12:48 +0000 Received: by zproxy.gmail.com with SMTP id x3so261081nzd for ; Fri, 02 Dec 2005 14:12:46 -0800 (PST) Received: by 10.36.66.12 with SMTP id o12mr1231560nza; Fri, 02 Dec 2005 14:12:46 -0800 (PST) Received: by 10.37.2.6 with HTTP; Fri, 2 Dec 2005 14:12:46 -0800 (PST) Message-ID: <8f2776cb0512021412n17d2a8b2rf8cb4a48daa9449e@mail.gmail.com> Date: Fri, 02 Dec 2005 22:12:00 -0000 From: Jim Blandy To: gdb@sourceware.org Subject: Re: [RFC] plugin/extension interface In-Reply-To: <200512021936.jB2JaZ6n014666@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <439090FE.8040502@st.com> <200512021936.jB2JaZ6n014666@elgar.sibelius.xs4all.nl> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00010.txt.bz2 I'm not so hostile to plug-in interfaces. It's true that the API needs to be designed carefully, but allowing people to maintain other features (targets; architectures; commands) separately from GDB would take a big load off our backs. It's true that plugin interfaces weaken the incentives the GPL tries to create, but while I think that was very important even five years ago, I don't think that's such a big deal any more. Maybe I don't get out enough, but I think there's already a consensus building that Open Source is simply the preferable way to develop programmers' tools, and most companies are just doing it freely, not because they have to use GPL'd ode. libthread_db has been a debacle, but I'd argue that's because it was designed for Solaris, and we lacked the option of adjusting the interface to better suit other systems. For example, the API doesn't abstract the process of stopping or continuing threads, meaning that it doesn't have the information it needs to cache things accurately in some cases (leading to bad performance) and that GDB pays the price in complexity of supporting the plugin interface, but ends up knowing a lot about the thread implementation anyway, so it doesn't get much benefit.