svn commit: r245259 - projects/utrace2

[John Baldwin]

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.

-- 
John Baldwin