site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com <http://www.macosxhints.com/article.php?story=20060817044149264> and Amit's book covers it in detail in chapter 11. <http://developer.apple.com/wwdc/tracks/macosx.html> -- Terry _______________________________________________ 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... On Jun 5, 2007, at 5:05 AM, Quinn wrote: At 7:51 -0400 5/6/07, Michael Cashwell wrote: Really?? Is this a change in policy? I had a mental post-it on fsevents that it was akin to an SPI and not really meant for general 3rd party use. Yes. One of the downsides of having direct access to kernel engineers via this mailing list is that they sometimes forget what's public API and what's not. They've been working on Leopard for a long time (-: Actually, there's "FSEvents" tracks announced for WWDC that show up for any "fsevents site:apple.com" search, and there's some documentation on <http://developer.apple.com>. But I meant "/dev/fsevents", for which there is also a "hints" article at: But Quinn's right, we don't recommend using it at present; it's just better than the alternative, in this case. 8^/. Anyway, for the record, we're introducing a public API for fsevents in Leopard, but on current released systems there's no supported API for accessing it. You can talk to /dev/fsevents directly (reverse engineering the protocol from the Darwin kernel source), but that's unsupported. Specifically, it's possible that that the interface to /dev/fsevents will change over time: if you talk to the public API, you'll be isolated from this change; if you talk directly to / dev/fsevents, you won't. There's a non-supported API, however, which is what I was referring to. It's also possible to hook into the KAUTH system to implement your own notification mechanism (this is what the virus scanners do). btw If you look at the public session information for WWDC, you'll see that we have a session that discusses the new-in-Leopard public API (the FSEvents framework). It should be a good session, and it's an API that I've been eagerly waiting for a long time. Once Leopard ships it would be reasonably safe to use /dev/fsevents prior to Leopard. That is, write code that using the FSEvents framework on Leopard and later, and separate code that using /dev/ fsevents on 10.4.x. Once Leopard ships, it's unlikely that we'll do any significant revisions to /dev/fsevents. It's still a risk, but it's a much smaller risk. Actually, for Leopard, you will want to use the framework, for sure, rather than the device directly. The device requires that you be root to open it, because if you are non-responsive to events coming in, then you can stall operations in the kernel. If you go the /dev/ fsevents route from the "hints" article, make sure you allocate a separate thread whose only job is to dequeue events from the kernel as quickly as possible, and deal with any latency/bottlenecks in user space. This email sent to site_archiver@lists.apple.com