Date: Mon, 14 Jan 2013 14:58:23 -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: <50F4635F.9010101@mu.org> In-Reply-To: <201301141401.46622.jhb@freebsd.org> References: <201301101758.r0AHw6m7078896@svn.freebsd.org> <201301141240.58356.jhb@freebsd.org> <50F4520C.50500@mu.org> <201301141401.46622.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/14/13 2:01 PM, John Baldwin wrote:
> 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.
>
#include <stdio.h>
#include <stdlib.h>
int
main(void)
{
void *ptr = 0x52544c44;
realloc(ptr, 200);
}
-Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F4635F.9010101>