> > On a more general note, being new to DTrace I read the "how I patched a > > system call for an errant third party program" description and deduced > > that "fixing" programs (not just observing how they fail :-) is one of > > its design purposes. Am I mistaken, or is changing parameters/return > > values just one of those things that hasn't been done yet (but lines up > > properly with the intended use of the feature)? > > > I think you're wrong in deducing this. DTrace is first and foremost an > observability tool; once you've found where a problem lies in a > program/piece of code, you need to fix the code, not apply some kind of > over-engineered band-aid*.
You know, I can understand if band-aids are not part of DTrace's goal, but it is in a unique position to do some really cool things. Fixing broken code at the source is definitely best but may not be an option, especially for third-party, closed-source apps. Even for in-house code, a band-aid at critical times could be a lifesaver. Plus it would make a wonderful prototyping tool. $.02 -- This message posted from opensolaris.org _______________________________________________ dtrace-discuss mailing list [email protected]
