Date: Mon, 14 Jan 2013 12:40:58 -0500 From: John Baldwin <jhb@freebsd.org> To: Alfred Perlstein <bright@mu.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: <201301141240.58356.jhb@freebsd.org> In-Reply-To: <50F08363.5020909@mu.org> References: <201301101758.r0AHw6m7078896@svn.freebsd.org> <201301111029.23235.jhb@freebsd.org> <50F08363.5020909@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, January 11, 2013 4:25:55 pm Alfred Perlstein wrote: > On 1/11/13 10:29 AM, John Baldwin wrote: > > On Thursday, January 10, 2013 11:44:51 PM Alfred Perlstein wrote: > >> On 1/10/13 4:10 PM, John Baldwin wrote: > >>> On Thursday, January 10, 2013 12:58:06 PM Alfred Perlstein wrote: > >>>> Author: alfred > >>>> Date: Thu Jan 10 17:58:05 2013 > >>>> New Revision: 245259 > >>>> URL: http://svnweb.freebsd.org/changeset/base/245259 > >>>> > >>>> Log: > >>>> Project branch for utrace2(2) work. > >>>> > >>>> The original utrace(2) call from FreeBSD 2.2 did not offer a > >>>> standardized way to specify the type of data being traced. Examples, > >>>> a utrace(2) record of 3 words is assumed to be a malloc(3) utrace > >>>> point, while RTLD uses a string at the start of the utrace record. > >>>> > >>>> Instead of risking breaking 10+ years of existing code, utrace2 is > >>>> introduced which will include "type,version" tuple in the utrace > >>>> data to allow utilities such as ktrace to parse them safely. > >>>> > >>>> Additionally a namespace is provided for both the base system and > >>>> for developers wishing to make use of the utrace2(2) system so > >>>> there are no collisions. > >>> Hummm, when I added the RTLD ones, I figured the convention of using a 4 > >>> character signature at the beginning for future traces would suffice just > >>> fine (e.g., see ACPI tables and most other BIOS tables that all use 4 > >>> char signatures (_32_, $PIR, _MP_, etc.). It seems cumbersome to have a > >>> separate ktrace/kdump flag, esp. if the plan is to obsolete utrace(). > >>> In that case 'u' should just toggle both. > >> That is a good idea. My concern is how do we deal with random old > >> utrace data that may have been generated by old applications with > >> unstructured data? > > Let the users who wrote them cope with that. I suspect there are close to > > zero of those, and if someone was able to write something that used utrace(2) > > they should be clueful enough to cope. > Interesting. Care to explain why you feel we need to break these > consumers considering that the code not to break them is already written? First of all, are you sure you would break them? Let's say you add a new set of libthr traces that use a '_THR' signature as the first 4 bytes. Do you really expect that to break existing users? My point is that you are speaking of hypothetical users, and that we shouldn't completely rototill an interface if there isn't an actual reason to do so. What if there are zero users, doesn't that mean you are just making a gratuitous change for no reason? Also, utrace() is hardly a trivial feature. If you have figured out a way to use it, you can figure out how to deal with any changes to it. However, in my case I'm not suggesting any changes at all. I'm merely saying to leave it as-is, but to perhaps document that any future traces should use a leading 4-char signature as a way to disambiguate. I would make this suggestion mandatory for any "system" traces that might be added. In the highly likely case that any existing proprietary utrace records do not conflict with any hypothetical new "system" records in the future then this approach works fine without breaking any existing users or requiring any code changes. Your proposal requires everyone who might be using utrace() to adapt to the new utrace2() API instead. Which one do you think is more invasive to users of utrace()? > >>> Do you have any new traces you want to add that you couldn't do using the > >>> 4 char signature method? > >> The issue with the current system is that there is nothing separating > >> FreeBSD namespace from what an application developer may create. > > Do we really think there are any application developers doing this? Also, > > I think the integer version is far more prone to conflicts if any applications > > do ever use it than a 4-character signature. > > Interesting. In the branch I created I specifically said that the space > below 100 was for project use only. Yes, but two different applications might both use 101. > As far as a 4 character signature versus integer I am now very > confused. Isn't sizeof(char[4]) == sizeof(int) on most (all?) of our > platforms? The point of a character-based signature is it encourages more diverse signatures instead of everyone picking 101. > >> Any alternatives? Do we just have the convention that FreeBSD utrace > >> records start with underbar? "_"? Suggestions appreciated. > > Well, RTLD already starts with a non-underbar, but perhaps we could mandate > > that for any future traces. However, I have mostly assumed that there is > > little-to-no use of utrace() by applications and instead that the only real > > uses are in system libraries such as for malloc() and rtld's LD_UTRACE. Do > > you know of any applications that use utrace? > Interesting, I really don't know that many consumers of it, but I don't > see the need to break them if the code not to break them is already > written and ready for prime time. So why break them by obsoleting utrace()??? _You_ are the one wanting to introduce a change that will break the API of existing applications on future branches. In my opinion, the existing API should work fine for the foreseeable future, especially if we enforce the rule that new system traces follow the model of LD_UTRACE and use a signature, and your changes are simply gratuitous and a solution looking for a problem. > One particular consumer I know of was Kerimada, he actually used > utrace(2) malloc to write a leak detector, which is how I came across > this. I'm not sure how long his code has been posted, but it is > detrimental to break his code: > http://keramida.wordpress.com/2008/10/15/extracting-useful-info-from-freebsd-malloc-tracing/ I will say this one more time. I AM NOT ADVOCATING BREAKING ANYTHING. I am advocating leaving the existing API as-is as I feel it is sufficient. You are the one who is wanting to change the API. I don't think you have given a sufficient reason for changing the API. Can you name one use of utrace() that will be broken by just leaving it as-is and requiring new "system" traces to use a 4 character signature and supporting the existing malloc() traces as a legacy format? > > As far as future system uses, it might be neat to add some libthr traces > > (_THR?) to denote pthread operations like acquiring locks. OTOH, a better use > > of time for that might be porting ltrace to FreeBSD. > > > ltrace may be portable via the ktrace hooks, it would be relatively > clean to do so using the new utrace2(2) API. Uh, ltrace doesn't use ktrace at all. IIRC, it uses ptrace(). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201301141240.58356.jhb>