From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19179 invoked by alias); 13 Jan 2006 04:25:13 -0000 Received: (qmail 19168 invoked by uid 22791); 13 Jan 2006 04:25:12 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Jan 2006 04:25:11 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k0D4P9DE028166 for ; Thu, 12 Jan 2006 23:25:09 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k0D4P9119325; Thu, 12 Jan 2006 23:25:09 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k0D4P778009204; Thu, 12 Jan 2006 23:25:07 -0500 Message-ID: <43C72B46.60606@redhat.com> Date: Fri, 13 Jan 2006 04:25:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Mark Kettenis CC: brobecker@adacore.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] implement gcore on hp/ux References: <20060110171752.GL925@adacore.com> <200601102029.k0AKTfPh011880@elgar.sibelius.xs4all.nl> <20060112055529.GJ676@adacore.com> <200601122044.k0CKiCBC018804@elgar.sibelius.xs4all.nl> In-Reply-To: <200601122044.k0CKiCBC018804@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00137.txt.bz2 Mark Kettenis wrote: >>Date: Thu, 12 Jan 2006 09:55:29 +0400 >>From: Joel Brobecker > >>The whole patch is becoming too big in my opinion to be submitted >>in one go. If we agree on continuing on this path, then I will submit >>one or more preparatory patches (such as making the procfs target vector >>a template for instance), as needed. > > > That'd certainly be appreciated. I'll just chime in here, since I've done a lot of work on procfs.c. This is just FYI. There are actually two (major) flavors of /proc, and it's been tricky to keep procfs working smoothly for both of them. The old-style procfs uses ioctl calls (solaris 2.5, irix...), and the newer style uses only read and write (solaris 2.6 and beyond, Unixware...). Be sure you test changes on at least one instance of each.