Re: [PATCH] Refactor common/target-common into meaningful bits

[Luis Machado <lgustavo@codesourcery.com>]

On 08/05/2013 07:43 AM, Pedro Alves wrote:
> On 08/02/2013 09:48 PM, Tom Tromey wrote:
>> Pedro> These new target-resume.h, target-wait.h, target-waitstatus.h,
>> Pedro> target-waitstatus.c files might be looked at as actually something
>> Pedro> else.  This is code defining the interface between GDB core and
>> Pedro> target_ops, and as such is used by all sort of targets on the
>> Pedro> GDB side (remote.c, etc.).  I'm not sure they should go in the same
>> Pedro> directory as the *-nat.c, etc. files.
>>
>> These seem like classic "target" bits to me.
>
> Yep.  So, if we move the classic "target" bits to a "target/"
> module directory, and put the native bits in their own dir, we
> have:
>
>   target/resume.h
>   target/waitstatus.[c|h]
>   target/wait.h
>   nat/i386-nat.c
>   nat/linux-nat.c
>   nat/linux-ptrace.c
>   nat/linux-waitpid.c
>   etc.
>
> Is this what you're thinking of?  _This_, I'm fine with.
> No mix of native bits with generic "target" bits, which was
> my main worry.
>
> It's actually very similar to something else I suggested on IRC,
> but forgot to put in email form:  "IMO, the interfaces themselves would be
> in an include dir.  e.g., gdb/include/target-waitstatus.h or some such,
> and then we'd have gdb/nat/linux-nat.c, etc."
>
> What else goes in "target/" ?  remote.c, corelow.c, etc.?
> Do we move things into subdirectories beneath it too, for better
> submodule partitioning?  I didn't want to suggest starting a
> mass move, that's easy to overdo.  (That was the point at which I
> suggested that someone thinks this through, and comes up with an
> initial design/guide of what things will look like in the end, so
> that we can then discuss and hash it out.)
>

I was checking the discussion and the above is something i had in mind, 
that is, split the generic target (as in target_ops) bits into their own 
dir and slowly move native bits to a separate "nat", "low" or "native" 
directory as well. The nat bits would deal with the system API's to do 
debugging. The target bits would be data structure and generic bits not 
directly related to the system API's.

Seems to be a bit more organized this way.