site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Graham J Lee writes:

Justin, while this is only at best marginally related to what I think the OP was saying, I can think of a number of reasons to want to glue Slowlaris and Darwin together:

To add 2 more: 1) Dtrace I'm starting on a Solaris driver, and dtrace has already saved me hours of development time that would have been wasted on MacOSX (or linux, to be fair). Let's say you want to find out what kernel function is returning ENOMEM in response to a high level kpi call from your driver. You can either examine the source, looking for all possible reasons for ENOMEM, setup 2 machine debugging, setup breakpoints, and step through it, which could take hours or days. Or you could setup a dtrace probe, looking for functions that return ENOMEM. This took a few minutes, including googling for a script which did close to what I wanted. This is just one possible usage mode, there are plenty of other, likely better, reasons for it. You can read about dtrace at http://www.sun.com/bigadmin/content/dtrace/ 2) Crash dumps to disk enabled as default. There is absolutely no excuse for a production OS like MacOSX Server not to have crashdumps enabled by default. The current strategy of network dumps is quite a bit better than nothing at all, but it prevents you from enabling them by default. See: http://www.unixville.com/?q=node/view/39&PHPSESSID=07050b290cc37ec15da3f8a09... for a far better justification than I could ever give. There is no reason you'd need to take this from Solaris if there are licensing issues. All the BSDs do this as well, and you all have excellent kernel map walking code already in the kdb network crashdump code. Drew _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com