Google Groups

Re: Some Answers


Tomas Carnecky Jan 5, 2010 9:15 AM
Posted in group: MacFUSE
On 09/29/2009 12:49 AM, Amit Singh wrote:
> * Custom-compiled MacFUSE under a 64-bit kernel?
>
> I noticed that some of you are compiling/distributing a MacFUSE kernel
> extension for the 64-bit kernel. Simply recompiling it is not going to
> work--a bunch of non-trivial work is needed. If you simply recompile
> it (by commenting out the #ifdef guards, as I believe folks did),
> it'll load under K64 and might even appear to work. But at best,
> you'll get a kernel panic, and at worst, you'll get data corruption.
>
> You can "test" this yourself under K64. Use the custom-compiled
> version to mount some file system with a bunch of files. Then, from
> multiple terminal windows, cause some continuous file activity, say,
> some 'find' loops. You should get a kernel panic in no time.
>
> Unless you are a kernel developer who wants to "hack" on MacFUSE, I
> wouldn't advise you recompile MacFUSE, specially the kernel extension.
> Even if you do, distributing it is likely to cause pain and confusion.

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?

tom