Date: Fri, 11 Jan 2013 16:25:55 -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: <50F08363.5020909@mu.org> In-Reply-To: <201301111029.23235.jhb@freebsd.org> References: <201301101758.r0AHw6m7078896@svn.freebsd.org> <201301101610.43321.jhb@freebsd.org> <50EF98C3.3000200@mu.org> <201301111029.23235.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > >>> 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. 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? Maybe I am missing something? > >> What do you think about putting the old utrace(2) under COMPAT_FREEBSD9 >> and moving forward to a system that allows FreeBSD to have a separate >> namespace from application space? >> >> 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. 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/ Having been on the other side of such changes "the user will catch up" I truly find such decisions to impact my opinion very negatively of whatever project I'm utilizing that chooses to take that path, in particular when I see how easy it would have been for them to maintain some level of compatibility. If you'd like we can discuss the root cause as to why keeping things comfortably compatible is an issue for you: Is due to additional code? If so we can put the old utrace2(2) code under COMPAT_FREEBSD9, then we can have it gone. If it's due to kdump's u/U code, I think maybe we can merge them into just 'u' Other issues? Please expound, I would love to address how we can get this working. > > 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. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F08363.5020909>