Re: Reload VM hint? (James Bucanek)
Re: Reload VM hint? (James Bucanek)
- Subject: Re: Reload VM hint? (James Bucanek)
- From: Terry Lambert <email@hidden>
- Date: Tue, 5 Jun 2007 18:49:41 -0700
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:
<http://www.macosxhints.com/article.php?story=20060817044149264>
and Amit's book covers it in detail in chapter 11.
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.
<http://developer.apple.com/wwdc/tracks/macosx.html>
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden