[dtrace-discuss] Asynchronous signal handling in fasttrap provider

[James McIlree]

On Feb 19, 2007, at 10:44 AM, Adam Leventhal wrote:

> On Mon, Feb 19, 2007 at 05:23:25PM +0900, Saravanan S wrote:
>> Does this mean,I can mail the Apple team asking for a porting guide.
>> If so,can you please share their email ids.
>
> I'm sure some of them are subscribed to this list so feel free to  
> use this
> forum to make your appeal.

Saravanan,

	We do not have a porting guide, like many a project, that fell under
the pressure of "Is it done yet?" :-)

	As you may be aware, Apple is quite protective of any information that
hasn't been publicly disclosed, I will not be able to answer many  
questions about
our implementation until after it ships.

	In general, I've found the dtrace code to be exceptionally well  
written.
My only complaint to date is the fact that vowels apparently cost $20  
each when
naming structure fields :-).

	If you're porting from scratch, I would concentrate on getting just one
provider working, say syscall or fbt. You can comment out large  
sections of the
code while bringing up dtrace. DTrace will work with quite a bit of  
its functionality
missing, and you can incrementally add them back in as you gain  
understanding
of the inner workings. The test suite is your friend!

	There will likely be several places where you have mismatches between
whatever OS you are porting to and the Solaris implementation.  
Depending on how
often you plan on sync'ing with the Solaris source, you may find it  
advantageous
to write emulation libraries instead of rewriting the Solaris code.

	If you can delay making decisions on how to handle those situations
until later (when you have a better understanding of how DTrace  
works), you
may save yourself a few code rewrites. Bringing up syscall or fbt  
should be
possible without hitting any major mismatches, every OS I know of has  
either
system calls or function calls :-).

	James M