Re: [rfa/threads] Eliminate lin-lwp.c

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Sep 16, 2004 at 04:10:23PM -0400, Andrew Cagney wrote:
> 
> >>>>>>>>>You mean add a "lin-lwp.h" which exports everything so that 
> >>>>>>>>>"linux-nat.c" can construct that vector, or conversly have 
> >>>>>>"linux-nat.h" >>>export everything so that "lin-lwp.c" can construct 
> >>>>>>the vector?
> >>>>>>>>>
> >>>>>>>>>Bleauh! Such a separation is artifical (although perhaphs the 
> >>>>>>single >>>file should be called inf-linux.[hc]).
> >>>
> >>>>>
> >>>>>
> >>>>>Yes, that's what I meant.  I'd like to preserve the revision history
> >>>>>when possible.
> >>
> >>>
> >>>The revision history or the existing files and their contents?  The 
> >>>former is always available in CVS.  The later, as I noted, is just an 
> >>>artifical separation that will complicate the objective of cleaning up 
> >>>this code.
> >
> >
> >I find the ability to use cvs annotate and diff on a function extremely
> >valuable, and you'll make that much more awkward if you move them
> >around without a reason.  I was asking if you had a reason to create
> >this inconvenience.
> 
> Yes, I want to avoid any artifical organization that will complicate the 
> objective of cleaning up this code.
> 
> What we need to preserve is the accumulated knowledge of bugs and 
> mis-implemented features - we do that by extending our test infrastructure.

I do not think that leaving these functions where they are will
complicate the process of cleaning them up.  Could you explain
why you see this as a problem?

> >>>I do see merit in creating an a new inf-linux.c (to be consistent with 
> >>>inf-ptrace, and inf-child), and I think I'll revise the patch to do that.
> >
> >
> >Please don't.  It's the native support for Linux.  By GDB's existing
> >conventions it ought to be linux-*.
> 
> linux-inf.c?  inf-linux.c is equally (if not more) consistent with the 
> new inf-ptrace.c and inf-child.c.

inf-* are currently more or less target agnostic; just "unixy".  GDB
convention says that native support for Linux - that's what this is -
belongs in linux-nat.c.  If some of it is left in lin-lwp.c for
historical reasons, that's a separate issue.

-- 
Daniel Jacobowitz