This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Where is GDB going


>Peter Reilley wrote:
>>
>> This is a fine line to draw.   Is communicating to a proprietary
>> monitor OK if it is by ASYNC or TCP/IP but not if it is by
>> way of a library?
>
>The prime distinction I see is that communicating via ASYNC or TCP/IP is
>System Neutral. I can as easily communicate using TCP/IP from Solaris as
>I can from Windows or Linux.  There is no impediment to anyone using
>this interface on a device.  Using a proprietary library forces a user
>of GDB to use Windows or Nothing.  (The only current examples of this I
>find involve Windows DLL's)  It allows a Hardware Vendor to force a
>choice of OS on a GDB user because it is not supported otherwise.  GPL
>Code should allow one to support themselves, proprietary libraries
>prevent this, published communications specs do not.  Im not religiously
>fervent about this issue, but I think the distinction is pretty clear.
>The two examples in GDB's code I cited are the only examples of it I
>could find.  Apart from increasing choice I feel that closed source
>DLL's linked to GDB decrease choice.  If those vendors want GDB to work
>with their hardware then they should do it properly and not force people
>to use the vendors OS of choice.


There are two separate issues here; the channel of communication to
the target and the language (API) used to communicate with the target.
ASYNC, TCP/IP, library, pipes, etc; are all channels.   The content of the
communication is the language.

ASYNC and TCP/IP are widely available on different OS's.   Libraries
are less widely available and need to be ported.   OCD, one of your
examples, is available on Windows, Linux, and Solaris.  Manufacturers
have every incentive to support as many systems as possible but they
are generally limited in the resources that they can devote to the effort.

The language is generally proprietary, while there is probably a
public spec describing the language, the code in the target is not
open and not GPL'ed.

Gdb supports a number of channels of communication and a number
of different languages (API) of communication.

I don't think that you can distinguish between ASYNC and TCP/IP
on one hand and library calls on the other.   After all, ASYNC and
TCP/IP are library calls on most systems.   On commercial
systems those libraries are not GPL'ed.

If you object to gdb talking a proprietary  language to the target
then that is a reasonable line to draw.   The problem being that
most of them are proprietary.

In more general terms, I don't think that companies getting a "free
ride" off GPL'ed code is such a bad thing.   Yes, they may make some
money off it, but they contribute to it as well in terms of bug fixes
and additional GPL'ed code.   Should we cheer that IBM is
touting Linux and GPL'ed code?   I think that we should!

Pete.









Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]