Benjamin Fleischer wrote 2010-11-13 15.35:
Comparing:
a) the 2010-10-17 announcement by Benjamin of his build
MacFUSE 2.1.7 (10.6 i386, x86_64).dmg
b) the 2010-10-20 build by Tuxera of
macfuse-core-10.5-2.1.9.dmg
announced on 2010-10-26
The latter includes more more on the 64-bit locking, "should be a lot
more proper than the one previously published" but "only works on 10.6
at the moment".
No one but Tuxera really knows what was changed or improved.
Basically release a) features locking that is extremely conservative.
The entire kernel extension code is locked down with a 'huge lock' each
time a thread enters. I.e. if one call blocks on one file system, all
other MacFUSE file systems are also blocked until the call completes.
This is pretty unsuitable for general-purpose use, and was never meant
to be a final solution.
Release b) features per-filesystem locking and node locking which means
that filesystems are more independent of each other. The 'biglock' that
is associated with each file system is also released during external
calls that could block (otherwise deadlocks could result) but the node
lock stays in place most of the time to ensure that nobody modifies the
vnode that is being accessed. This is all a bit error-prone and needs to
be tested, which is why I posted a release with lots of debug messages.
Since nobody seems to have experienced any deadlocks, maybe it's time to
share the source code of this build:
http://www.tuxera.com/mac/macfuse-rebel-2.1.9-src.tar.bz2
Could be that the panic Zev encountered is locking related and could have been
avoided when using Tuxera's build.
A panic log would have been helpful, otherwise we cannot know what was
the cause. Panics are actually unlikely to result from the locking code
itself. If there's a problem with locking, the result is usually a
system-wide lockup (deadlock inside the kernel).
They might have already fixed the problem ... or not. Nobody knows since they
have not made their source code available.
See above for source code.
Could be that a third or fourth build will be released next week improving who knows
which feature. It seems kind of pointless to me to test that many builds rather than
having one development tree. I think it would be nice to have a new common source tree
and only one "semi-unofficial" build to test.
Agreed.
This way the same problem has to be fixed in only one source tree and everyone
could benefit from it. Much as it was when official MacFUSE was under active
development. If everyone focuses on their own builds the MacFUSE community,
which by the way does not seem too big, would scatter even further. What is
your opinion on that?
Benjamin, please: should test environments with 64-bit kernel
capability focus on testing (b), whilst testers in a 10.5.x
environment limit themselves to your (a)?
As I wrote in my first post the version I released was compiled using the Mac
OS X 10.6 SDK. I set the min supported version to 10.6. So I guess my build
will not work with 10.5. The only thing that might work in 10.5 is the core
fuse.fs component, which would not compile with min version set to 10.6, so I
set it to 10.5 for this component only. I have never tested weather my build
works with 10.5. I do not have a Mac running 10.5 natively. I solely focused on
10.6 (and intel architecture) since there should be no need for a 64 bit build
in Leopard. As far as I know Leopard only brings along a 32 bit kernel (with
support for 64 bit applications). So Leopard users could stick to the latest
official beta release 2.1.5 which should be well tested.
That would probably be the best option (or 2.0.3 really).
That means there is no unofficial MacFUSE 2.17 or 2.19 (as Tuxera calls theirs)
build out there (that I am aware of) supporting Leopard.
I simply set the version to 2.1.9 to signal that it's different from the
previous build that was released from backporting the 'TUFS'
modifications. Version numbers can be discussed, this was just a test
release anyway.
We generally favour a YEAR.MONTH(.something)-type versioning scheme at
Tuxera.
- Erik
--
You received this message because you are subscribed to the Google Groups
"MacFUSE" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/macfuse?hl=en.
