svn commit: r245259 - projects/utrace2

[John Baldwin]

On Monday, January 14, 2013 1:44:28 pm Alfred Perlstein wrote:
> 
> I think we are basically in agreement, however we differ on the following two points, whereas now I think we only differ on a single point.
> 
> 1) belief that a 4 character string signature is superior to a protocol/version tuple.
> 
>   After looking at the code and thinking about this quite a bit, I agree with you that string based namespace is nicer, however I think we need the 
following changes:
>   a) define the system namespace to have "_" preceding the trace name.  so RTLD -> _RTL
>   b) or maybe we need another few characters? 6 or 8 so that it can still be nice. so "_RTL" -> "_RTLD\0\0\0", "_MALLOC\0"
>   c) we add a version field after the character string.
>   d) we create a mechanism for requesting a utrace allocation namespace somewhere (/usr/share/utrace/allocations.txt) where vendors can allocate 
strings.
> 
> 2) you believe that filtering this all through utrace(2) is OK.  I would prefer that we leave utrace(2) alone and move forward with utrace2(2) to 
leave behind all the unformatted data we used to have.  I would like to leave utrace(2) in the system and add utrace2(2) for new consumers.
> 
> What do you think?
> 
> My end goal is to make this something that more users can grab and use for a quick and handy debug tool and to actually build on this somewhat, 
(libutrace) what we have now (unstructured globs of whatever) does not work.

I disagree with this last assertion.  On what basis do you claim that what we
have now does not work?  Do you have any specific examples besides
hypothetical cases?  I fail to see how utrace() in its current form is not
already useful, and I've yet to see a convincing argument from you that it is
not.

-- 
John Baldwin