Re: [PATCH] Let gcore use ptrace interface rather than the procfs

From: Attilio Rao <attilio_at_freebsd.org>
Date: Thu, 19 Nov 2009 16:07:38 +0100
2009/11/19 Robert N. M. Watson <rwatson_at_freebsd.org>:
>
> On 19 Nov 2009, at 13:45, Attilio Rao wrote:
>
>>> If you add the missing include of sys/wait.h, elfcore.c generates an error
>>> instead of a warning on this non-traditional use of wait(2):
>>>
>>> +       wait();
>>>
>>> Something like this may be preferred:
>>>
>>>       if (waitpid(pid, NULL, 0) < 0)
>>>               err(1, "waitpid");
>>
>> I didn't get a warning neither an error but yes, the waitpid() is
>> preferred and should be used.
>
> This warning was on i386 9.x, FYI, and was a property of failing to call wait(2) with an argument.
>
>>> I think that kills the last of the procfs dependencies, in which case
>>> perhaps we can remove the procfs.h include from elfcore.c, which requires
>>> defining a local version of a summary data structure borrowed from procfs.
>>> It's worth trying with procfs unmounted, however, to make sure they're
>>> really all gone (which is how I ran into the above problem).
>>
>> I don't like the idea to replicate the structures because of code
>> maintence. IMHO is ok to have procfs header.
>
>
> I'm not sure I agree; looking at the elfcore code, it looks like it goes to some amount of inconvenience to stuff things into the structure in the first place, primarily because that was how procfs exported it. With your excellent change, there's no need for gcore(1) to depend on procfs-specific data structures that may change, or more ideally, be removed in the future.

Yeah, I had the same feeling as the interfaces should be more lifted
in order to less fit procfs (example: probabilly readmap could export
directly the list of objects from libutil rather then transforming it)
but let's get there in a second round of changes probabilly.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
Received on Thu Nov 19 2009 - 14:07:41 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:58 UTC