Failing kernel32:change and ntdll:change tests on Mac OS

[Charles Davis]

Hi,

I just got done looking over the latest batch of test results I sent,
and one thing really sticks out and bothers me.

The Change Notification tests all fail miserably on my machine (a 2009
Mac Pro with Mac OS X 10.6), because that feature hasn't been
implemented on Mac yet.

I could implement it for 10.5 up, but the problem is that the "public"
API for Change Notifications on Mac (the "FSEvents" API, in
CoreServices.framework) expects clients to either use a CFRunLoop or (on
10.6 and up) a GCD dispatch queue. I'm sure this won't sit well with AJ.

I did some digging, and it turns out that FSEvents just uses a Mach port
(whose name is published in root's Mach bootstrap context as
"com.apple.FSEvents") to talk to a daemon, fseventsd, which in turn
opens a device file, /dev/fsevents, which is the actual gateway to the
kernel. Though it's largely undocumented, we could use this device file
to implement Change Notification. The FDs that get returned by this file
even support kqueues. But, there are two tiny problems with that:

1) You have to be root to open /dev/fsevents. If we do it this way, we
will have to wait until the server is converted to run as root.
2) Because this API isn't officially documented, it's unstable and
subject to change. (In fact, judging from the kernel source, it's
already changed once. There are several 'old' and 'new' variants of the
FSEvents ioctls that the kernel handler supports.)

I guess the real question is, which way should we do this? If we do it
the first way (using the public and documented but kqueue-unfriendly
Carbon API), wineserver has to use a CFRunLoop (or, if we're no longer
concerned about Leopard, a GCD dispatch queue) in its main loop, and if
we do it the second way (using the undocumented and unstable but
kqueue-friendly Unix API), wineserver needs to run as root, and may need
to cope with API changes. Based on what I've heard, I'm leaning toward
the second way, but I want your guys' input before I go ahead.

Thanks.

Chip