From owner-freebsd-current@FreeBSD.ORG Mon Nov 23 15:29:09 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 98D17106568F; Mon, 23 Nov 2009 15:29:08 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id C9D928FC13; Mon, 23 Nov 2009 15:29:07 +0000 (UTC) Received: by fxm10 with SMTP id 10so2945901fxm.14 for ; Mon, 23 Nov 2009 07:29:06 -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:content-transfer-encoding; bh=7QyFbfsP2JjK/KXdmSNenekBaUQmFGndXq9C0nMKeMs=; b=NwWbwVIoyCIsBRdS8AOu196oBWoecYQQdA3lNrS4Keib5O+7pDOv1gb3k4eL5Ls0yK oypPnujAFx3rw2xdJh+SmMX5YzmpDSdTJt8oY9BGOnkRTF3St7xGUOjajlfVu7CyuPUX BoHVfWCY7FHfkzUNKthBuL7CkR86jL8L46NuU= 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 :content-transfer-encoding; b=r0qcnQYg5DeT7/07e/EmoGsV31vymelgM5TMmOzmJwqX9ypjH4H/sobZo7FZWkcwob mR9OyiUYJQAYkwLWuj3fM6ml8xMfmadvacyhLjmNaUJgXMBMpM1Np1Zry25zemzjEM8l z14bdx79ByZ4AzDuugQwJShm7mz1d98jQaCOg= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.74.91 with SMTP id t27mr762089faj.62.1258990146730; Mon, 23 Nov 2009 07:29:06 -0800 (PST) In-Reply-To: <3bbf2fe10911190707w63d1ab66pa2014c526342f68e@mail.gmail.com> References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> <20091117141713.GA51251@sandvine.com> <9C740225-CB30-4D26-8E4B-F9D5DC51B899@FreeBSD.org> <3bbf2fe10911181733j598083feiddf3d4b34d0007d6@mail.gmail.com> <3bbf2fe10911190545l264c0e2s615034999f46bc0a@mail.gmail.com> <645CAAD7-A3BE-44B3-97D5-F4E4786943A4@freebsd.org> <3bbf2fe10911190707w63d1ab66pa2014c526342f68e@mail.gmail.com> Date: Mon, 23 Nov 2009 16:29:06 +0100 X-Google-Sender-Auth: 650e050d628a3c2b Message-ID: <3bbf2fe10911230729l787f6e28n142916c5a580273b@mail.gmail.com> From: Attilio Rao To: "Robert N. M. Watson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Mon, 23 Nov 2009 15:29:09 -0000 2009/11/19 Attilio Rao : > 2009/11/19 Robert N. M. Watson : >> >> On 19 Nov 2009, at 13:45, Attilio Rao wrote: >> >>>> If you add the missing include of sys/wait.h, elfcore.c generates an e= rror >>>> 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 requi= res >>>> defining a local version of a summary data structure borrowed from pro= cfs. >>>> 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 e= xcellent 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. This further patch should address the last reported issues and a couple of style nits: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore3.diff Please also note that I added the Sandvine's copyright because I think the extent of the changes deserve it. Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein