Date: Wed, 16 Jan 2013 10:54:16 -0800 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: <50F6F758.5050302@mu.org> In-Reply-To: <201301161342.49065.jhb@freebsd.org> References: <201301101758.r0AHw6m7078896@svn.freebsd.org> <201301151443.25121.jhb@freebsd.org> <50F5D935.2010309@mu.org> <201301161342.49065.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/16/13 10:42 AM, John Baldwin wrote:
> On Tuesday, January 15, 2013 5:33:25 pm Alfred Perlstein wrote:
>> On 1/15/13 11:43 AM, John Baldwin wrote:
>>> On Monday, January 14, 2013 4:35:07 pm Alfred Perlstein wrote:
>>>> On 1/14/13 3:32 PM, John Baldwin wrote:
>>>>> On Monday, January 14, 2013 2:58:23 pm Alfred Perlstein wrote:
>>>>>> 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);
>>>>>> }
>>>>> That is fair, though you could easily fix that by changing malloc to use a
>>>>> signature going forward. :) That is a far simpler change than adding an
>>>>> entirely new system call. You also ignored the point that by making an API
>>>>> change you _are_ forcing all the current hypothetical utrace() users you are
>>>>> so worried about to make a code change.
>>>> Well, wouldn't the hypothetical users just continue to use the old code
>>>> until they are ready to move forward? Having both utrace and utrace2
>>>> would not impact force anyone to move.
>>> Presumably if you really want to deprecate it you need to remove it from the
>>> header so it is truly hidden? (At least in 11 if not in 10?)
>> I don't really want to deprecate it. I just want to provide a new
>> subsystem that's more regular.
>>
>> I only offered to deprecate it because I thought you were hinting at that.
>>
>> I'd rather keep both old and new. I do NOT want to break people.
> Ok. I can't think of a better name than utrace2() in that case. I still think
> -u should enable both utrace() variants for ktrace and kdump. It would be nice
> if you were to support a 4 char signature of some sort and have kdump display
> that instead of 'USER', so you get:
>
> <pid> RTLD dl_open(...)
>
> vs the current:
>
> <pid> USER RTLD: dl_open(...)
>
> and so that you can specify that 4 char for a filter list somehow (maybe -U
> accepts a comma-separated list of signatures for "user events"?).
>
> If you want to keep integers instead of encoding the signature in the tag
> values then you could use a table for the system-assigned tags to map them
> to a signature. OTOH, if we just encode the signature as the tag then kdump
> would automatically support "new" tags (including user-assigned tags) for
> purposes of filtering, etc.
>
I think I can get this all done. It will be a few days before I can get
back to this unfortunately.
I'll ping you for review/testing/feedback.
Thanks John.
-Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F6F758.5050302>