From owner-svn-src-projects@FreeBSD.ORG Fri Jan 11 20:42:03 2013 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3864F93C; Fri, 11 Jan 2013 20:42:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0A549F70; Fri, 11 Jan 2013 20:42:03 +0000 (UTC) Received: from ralph.baldwin.cx (c-68-39-198-164.hsd1.de.comcast.net [68.39.198.164]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2CA21B95B; Fri, 11 Jan 2013 15:42:02 -0500 (EST) From: John Baldwin To: Alfred Perlstein Subject: Re: svn commit: r245259 - projects/utrace2 Date: Fri, 11 Jan 2013 10:29:23 -0500 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201301101758.r0AHw6m7078896@svn.freebsd.org> <201301101610.43321.jhb@freebsd.org> <50EF98C3.3000200@mu.org> In-Reply-To: <50EF98C3.3000200@mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201301111029.23235.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 11 Jan 2013 15:42:02 -0500 (EST) Cc: svn-src-projects@freebsd.org, Alfred Perlstein , src-committers@freebsd.org X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 20:42:03 -0000 On Thursday, January 10, 2013 11:44:51 PM Alfred Perlstein wrote: > On 1/10/13 4:10 PM, John Baldwin wrote: > > On Thursday, January 10, 2013 12:58:06 PM Alfred Perlstein wrote: > >> Author: alfred > >> Date: Thu Jan 10 17:58:05 2013 > >> New Revision: 245259 > >> URL: http://svnweb.freebsd.org/changeset/base/245259 > >> > >> Log: > >> Project branch for utrace2(2) work. > >> > >> The original utrace(2) call from FreeBSD 2.2 did not offer a > >> standardized way to specify the type of data being traced. Examples, > >> a utrace(2) record of 3 words is assumed to be a malloc(3) utrace > >> point, while RTLD uses a string at the start of the utrace record. > >> > >> Instead of risking breaking 10+ years of existing code, utrace2 is > >> introduced which will include "type,version" tuple in the utrace > >> data to allow utilities such as ktrace to parse them safely. > >> > >> Additionally a namespace is provided for both the base system and > >> for developers wishing to make use of the utrace2(2) system so > >> there are no collisions. > > > > Hummm, when I added the RTLD ones, I figured the convention of using a 4 > > character signature at the beginning for future traces would suffice just > > fine (e.g., see ACPI tables and most other BIOS tables that all use 4 > > char signatures (_32_, $PIR, _MP_, etc.). It seems cumbersome to have a > > separate ktrace/kdump flag, esp. if the plan is to obsolete utrace(). > > In that case 'u' should just toggle both. > > That is a good idea. My concern is how do we deal with random old > utrace data that may have been generated by old applications with > unstructured data? Let the users who wrote them cope with that. I suspect there are close to zero of those, and if someone was able to write something that used utrace(2) they should be clueful enough to cope. > > Do you have any new traces you want to add that you couldn't do using the > > 4 char signature method? > > The issue with the current system is that there is nothing separating > FreeBSD namespace from what an application developer may create. Do we really think there are any application developers doing this? Also, I think the integer version is far more prone to conflicts if any applications do ever use it than a 4-character signature. > What do you think about putting the old utrace(2) under COMPAT_FREEBSD9 > and moving forward to a system that allows FreeBSD to have a separate > namespace from application space? > > Any alternatives? Do we just have the convention that FreeBSD utrace > records start with underbar? "_"? Suggestions appreciated. Well, RTLD already starts with a non-underbar, but perhaps we could mandate that for any future traces. However, I have mostly assumed that there is little-to-no use of utrace() by applications and instead that the only real uses are in system libraries such as for malloc() and rtld's LD_UTRACE. Do you know of any applications that use utrace? As far as future system uses, it might be neat to add some libthr traces (_THR?) to denote pthread operations like acquiring locks. OTOH, a better use of time for that might be porting ltrace to FreeBSD. -- John Baldwin