From owner-svn-src-projects@FreeBSD.ORG Wed Jan 16 18:54:21 2013 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 118901A6; Wed, 16 Jan 2013 18:54:21 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id C0D782C6; Wed, 16 Jan 2013 18:54:20 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id EE7DD1A3DC7; Wed, 16 Jan 2013 10:54:17 -0800 (PST) Message-ID: <50F6F758.5050302@mu.org> Date: Wed, 16 Jan 2013 10:54:16 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: svn commit: r245259 - projects/utrace2 References: <201301101758.r0AHw6m7078896@svn.freebsd.org> <201301151443.25121.jhb@freebsd.org> <50F5D935.2010309@mu.org> <201301161342.49065.jhb@freebsd.org> In-Reply-To: <201301161342.49065.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-projects@freebsd.org, Alfred Perlstein , src-committers@freebsd.org X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 18:54:21 -0000 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 >>>>>> #include >>>>>> >>>>>> 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: > > RTLD dl_open(...) > > vs the current: > > 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