Date: Thu, 10 Jan 2013 23:44:51 -0500 From: Alfred Perlstein <bright@mu.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-projects@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r245259 - projects/utrace2 Message-ID: <50EF98C3.3000200@mu.org> In-Reply-To: <201301101610.43321.jhb@freebsd.org> References: <201301101758.r0AHw6m7078896@svn.freebsd.org> <201301101610.43321.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > > 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. 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. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50EF98C3.3000200>