If you look in the XNU source code here:
Some way down in the source code you will find the following comment:
/* Non-threadsafe filesystems are not supported for K64 */
So far MacFUSE has been able to get by just by not passing the
VFS_TBLTHREADSAFE flag in the file system capabilities (see fuse_vfsops.c).
This is not possible anymore in K64 (the kernel extension just won't
load if it's not thread safe).
I suppose Amit was planning to do an initial biglock approach for
MacFUSE (maybe one big lock for all the MacFUSE kernel extension code?),
but it's not implemented yet (the fuse_biglock_vnops.* files).
I'm not 100% sure of the implications, but I could think of trying out
an approach with a big mutex protecting all the vnops (and vfsops?).
Let me know if you want to cooperate on solving this.
Tomas Carnecky wrote 2010-01-05 18.15:
> Do you at least know what needs to be changed or are you completely in
> the dark as to which changes there have been in Snow Leopard which make
> the 64bit MacFUSE kext incompatible?
> If you know that you don't have time to work on MacFUSE maybe you should
> make an announcement to the group that you are looking for someone to
> take over the project. I don't think anybody is going to rush to work on
> it given the uncertainty whether you will pick it up in the future or not.
> I'd probably work on MacFUSE as far as I can. But where do I start? What
> needs to be done in the MacFUSE kext? What was that
> fuse_biglock_vnode_operation_entries about? Why does the 64bit kernel
> need locking where the 32bit kernel doesn't? Did you plan to use
> something like the Linux Big Kernel Lock (BKL, basically a single lock
> for the whole kernel)? Or which data structures need to be protected
> from concurrent access?
> I see the current source has 'XXX: Locking' comments in a few places
> throughout the vnops code. Does that mean that the current vnops code
> doesn't use any locks? Is that safe in 32bit kernels?