[dtrace-discuss] Asynchronous signal handling in fasttrap provider

[Steve Peters]

On Feb 19, 2007, at 3:01 PM, James McIlree wrote:

>
> 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
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Saravanan,
Everything James said, and ....
I started the Mac OS X DTrace port on the *user* side, bringing up  
libdtrace and the dtrace(1) command line tool. Depending on your OS,  
lex/yacc "features" will require some taming. With a working dtrace 
(1), you can begin to think about a rudimentary kernel device driver  
that can answer to open/close/ioctl. The beautiful craftsmanship of  
the DTrace code makes all of this a pleasant and fun exercise.

SCP
--
Steve Peters
scp at mac.com