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

[Daniel Jacobowitz <drow@false.org>]

On Thu, Sep 16, 2004 at 05:11:27PM -0400, Andrew Cagney wrote:
> >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?
> 
> As with inf-child and inf-ptrace, an important objective here is to get 
> all the inf-linux methods local to a file so that we can ensure that all 
> accesses are strictly via the target vector.  Leaving them where they 
> are defeats this, a little.

So the reason you want them all in one file is so that you can make
them all static, and ensure they aren't accessed "on the side".  Is
that right?  That's a good technical reason for this patch, one which I
didn't think of and you didn't explain.  I'm just trying to get you to
share your wisdom with all us other maintainers.

With that explanation presented, I have no objection.  Let's make sure
Michael agrees.

> >>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".
> 
> inf-child, the current root object is very un "unixy".

Hmm, that's because it doesn't do anything.  I hadn't looked
since you created the new inf-* files (the confusion with inf*, ugh!).

> > 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.
> 
> Here we're going to end up with:
> 
> 	inf-i386-linux is-a inf-linux (is-a inf-ptrace?) is-a inf-child
> 
> Lets not be shy with the code base.  inf-linux.c, containing the 
> inf-linux class, is going to be far more consistent in the long term. 
> (the only alt I see is a name reversal of linux-inf, child-inf, 
> ptrace-inf, ...).

I'm saying that don't see the point of this renaming.  Having the
native support for GNU/Linux, whatever it inherits from, continue to
live in linux-nat.c is more natural to me.

> What about I fix up i386 and then come back for the others?

I don't understand what you mean.

-- 
Daniel Jacobowitz