From owner-freebsd-current@FreeBSD.ORG Thu Nov 19 13:45:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA3941065676; Thu, 19 Nov 2009 13:45:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 00DAC8FC1C; Thu, 19 Nov 2009 13:45:05 +0000 (UTC) Received: by mail-bw0-f213.google.com with SMTP id 5so2579666bwz.3 for ; Thu, 19 Nov 2009 05:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=avmufNLLPqdOgmeO+GGGVSATSeu9HvuoZF8JEOEVbSg=; b=WNLhGOo6gU94GQ7Y8mJz+ORkuBwpaPa64CgpG0QZDYGY7Z+aSGI3siiy+KLag0skOq T1l8JW6AfNWM0bj6wCucNYKasMkO0axIrtZKwRIhGHhAkGcKUwxkQRMg55kbK2/nVlDR 8oEt9r1s89UW7rQfYyVFktAqIoyOk08WNr4Yc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Qe3ow8vpnWjxtN5qXtdfF/fd9zK9TyyjACc36yduvHknPmo8cdWMcx5sMEY2DkbZJg yhzzfzSQcAYlc7IDA5X5mRvXomSgW7giaF3yQ2il3wFWi4eoODq+Zx2b4x6lAF/0AkF9 FRE5HhUZ3JarwKCwhYaayZBdwD0PMBj0H8/TI= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.18.137 with SMTP id w9mr992035faa.61.1258638305518; Thu, 19 Nov 2009 05:45:05 -0800 (PST) In-Reply-To: References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <20091117141713.GA51251@sandvine.com> <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> Date: Thu, 19 Nov 2009 14:45:05 +0100 X-Google-Sender-Auth: 52fabe9d60638563 Message-ID: <3bbf2fe10911190545l264c0e2s615034999f46bc0a@mail.gmail.com> From: Attilio Rao To: Robert Watson Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 13:45:07 -0000 2009/11/19 Robert Watson : > > On Thu, 19 Nov 2009, Attilio Rao wrote: > >> 2009/11/17 Robert N. M. Watson : >>> >>> On 17 Nov 2009, at 14:17, Ed Maste wrote: >>> >>>> Our original motivation for doing this was to make gcore work with >>>> threaded apps, not avoiding procfs, but that's a useful side-effect of the >>>> work. Note though that for that purpose it isn't complete; procfs is still >>>> used in readmap to read the process' memory map. It looks like we need to >>>> find a way to implement readmap without procfs. >>> >>> Are the sysctls used for procstat -v sufficient for this purpose? >> >> This patch should address the arised concerns by both of you: >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore2.diff >> >> and additively fix elf_getstatus() to not use procfs, so that gcore is >> completely procfs independent now. Comments, reviews and testing are >> welcome. > > 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 further persisting reference to procfs can be replaced with a > sysctl/kvm interface: > > gcore.c: asprintf(&binfile, "/proc/%d/file", pid); Right, I just modified elfcore so I missed it. > See the implementation of "procstat -b" which returns the path to the binary > using the same underlying mechanism (vn_fullpath on the process image > vnode). > > 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 will provide ASAP a new patch which addresses this concerns and testing without procfs mounted. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein