Date: Fri, 11 Jan 2013 10:29:23 -0500 From: John Baldwin <jhb@freebsd.org> To: Alfred Perlstein <bright@mu.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: <201301111029.23235.jhb@freebsd.org> In-Reply-To: <50EF98C3.3000200@mu.org> References: <201301101758.r0AHw6m7078896@svn.freebsd.org> <201301101610.43321.jhb@freebsd.org> <50EF98C3.3000200@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301111029.23235.jhb>