This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH RFC] Make lin-lwp.c functions use target vectors,part 1
- To: gdb-patches at sources dot redhat dot com,Mark Kettenis <kettenis at wins dot uva dot dot dot nl>
- Subject: Re: [PATCH RFC] Make lin-lwp.c functions use target vectors,part 1
- From: John S. Kallal <jskallal at home dot com>
- Date: Tue, 22 May 2001 23:36:37 -0400
- Reply-To: jskallal at home dot com
Hi Mark,
>As you've noticed, the code in lin-lwp.c does some very low-level
>things. In fact it is so closely tied to the "child_ops" layer, that
>I don't feel comfortable applying your patch, even though in the long
....
I will talk about this in my next message.
>That said, there are two obstacles when contributing code to GDB. The
>first is a copyright assignment: copyrights for any significant
>changes need to be assigned to the FSF before we can include them in
>the GDB sources. This can take a bit of time, so if you're serious in
>contributing to GDB, make sure the paperwork gets done.
Copyright assignment sent in to FSF in May of 1999 for GCC, GDB,
GAS, and BINUTILS. Copy of assignment papers received back from
the FSF in June of 1999. My employer's disclaimer runs until 2002
April. Likely no problem with an extention of the employer's
disclaimer, as long as it helps with my current work.
I read someplace that maintainers had access to a name list
for those who had provided assignment papers. I assumed that
my name was on such a list.
I send the patches from my home linux computer. My development
computer at work does not have Internet access. At work, I can
only download files or do WWW viewing from a computer that is
isolated from my companie's internal network. This creates a
delay in my responses and make sending patches time-taking.
However, if I take to much of my working time to get my changes
into the development gdb sources I may be instructed to stop
creating patches and only create something from the current gdb
snapshot. Under such limited time conditions, good coding and
proper formating just do not get done.
For a future company project, threaded program debugging on an
embedded linux system will be needed. I think having most of
my changes go into the next version of gdb may be helpful over
the long run for this project. Even if all the changes I need
do not get installed into GDB having most of my changes would
reduce the size of patching on a future released or snapshot
gdb versions.
>The second point is that code has to conform to the GNU/GDB coding
>standards. Your code currently doesn't, so I'd suggest you look at
>the GNU coding standards and the suggestions on the GDB web pages.
I will send a upated patch.
If this updated patch has formating errors, can you be more detailed
about where I am not meeting the coding standards? Is it in the
changelog entry? Is it in the diff output of the change to the source
code? Reformating the changed lin-lwp.c file with indent before making
the patch, caused a much larger patch and mixed many other changes
into diff's output. The current snapshot version of lin-lwp.c does
not seem to be fully following GNU formating. I was told NOT to mix
code clean-ups and code changes together. However, my patches for
only code clean-up seem to be just ignored even after many weeks.
For example, see the patch I made when reviewing the gdbserver code at:
http://sources.redhat.com/ml/gdb-patches/2001-04/msg00256.html
John S. Kallal