svn commit: r245259 - projects/utrace2

[John Baldwin]

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