Date: Thu, 19 Nov 2009 14:40:01 +0000 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Attilio Rao <attilio@freebsd.org> Cc: freebsd-current@freebsd.org, Ed Maste <emaste@freebsd.org> Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs Message-ID: <645CAAD7-A3BE-44B3-97D5-F4E4786943A4@freebsd.org> In-Reply-To: <3bbf2fe10911190545l264c0e2s615034999f46bc0a@mail.gmail.com> References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <alpine.BSF.2.00.0911171120050.47035@fledge.watson.org> <20091117141713.GA51251@sandvine.com> <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> <alpine.BSF.2.00.0911190757430.12162@fledge.watson.org> <3bbf2fe10911190545l264c0e2s615034999f46bc0a@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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): >>=20 >> + wait(); >>=20 >> Something like this may be preferred: >>=20 >> if (waitpid(pid, NULL, 0) < 0) >> err(1, "waitpid"); >=20 > 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). >=20 > 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. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?645CAAD7-A3BE-44B3-97D5-F4E4786943A4>