Kernel extensions in MacPorts

Salvatore Domenick Desiano sal at
Mon Jan 15 09:21:10 PST 2007

o with svn HEAD yet), there's no support for a pre-deactivate hook. A 
o pre-deactivate hook would be necessary here in order to attempt to 
o kextunload the MacFUSE kext (I'm assuming it can be unloaded once 
o loaded, if no FUSE filesystems are mounted, but I don't actually know 
o that for a fact). Alternately, if the kext cannot be unloaded, a 
o post-deactivate hook would be necessary to tell the user that they 
o have to reboot. Alternately this could be done in a pre-deactivate 
o hook that prompts the user if they really want to continue, knowing 
o they'd have to reboot.

While the hooks are probably the *right* way to do this, it occurs to me 
that our other packages are not nearly as responsible and perhaps 
MacFUSE does not need to be either. That is, none of our packages shut 
themselves down before being removed (Apache comes to mind, but any of 
the daemons are examples).

The "port" command generally handles installation (which includes adding 
hooks for activation) and deinstallation (which includes removing those 
hooks), but often does not include running the hooks. In some packages, 
the port command finishes with a message like "you may want to run X to 
activate this package" (the mysql port comes to mind).

So, if that's the only blocker, I think you're in good shape to do just 
as good a job with MacFUSE as we do with other ports. Adding 
pre/post-activation hooks could be viewed as a separate task to improve 
the MP project as a whole.

-- Sal

  Salvatore Domenick Desiano
    Doctoral Candidate
      Robotics Institute
        Carnegie Mellon University

On Mon, 15 Jan 2007, Kevin Ballard wrote:

o I've been looking into the feasibility of providing a port for MacFUSE (note:
o I'm Eridius). Unfortunately, I believe doing so will require some changes to
o the MacPorts codebase.
o The biggest problem is, at least with the official release (I haven't tested
o Actually, offhand that's the only real problem I can think of, though I
o thought there were others. Maybe I'll remember others later, maybe not. In any
o case, the pre/post-deactivate hook is pretty important here. And actually, I
o want a pre-deactivate hook for another port, so it's probably worth doing
o regardless of MacFUSE.
o In any case, we also want a source distribution of MacFUSE available for this.
o I've filed a ticket on the MacFUSE project, so hopefully it'll happen. If not,
o somebody could always host one, but I'm hoping for an official one.
o Perhaps I'll try contacting Amit Singh later to get his input on this.
o If you're interested in helping out regarding getting MacFUSE into MacPorts,
o I'm willing to be responsible for seeing this happen, so feel free to talk to
o me. Best way is to contact me on IRC, I go by Eridius and I hang out on the
o #macports channel. Alternatively you can reach me as Aranor8 on AIM, or at
o <eridius at>.
o -Kevin Ballard a.k.a. Eridius
o On Jan 14, 2007, at 11:23 AM, Pierre Queinnec wrote:
o > Eridius pointed me on IRC to MacFUSE, the recently released FUSE port to OS
o > X. I wanted to see if there is interest in having it in our ports.
o > 
o > There is a major drawback in having kernel modules in the ports in the fact
o > that it's a tad easier for curious & inexperienced users to mess up their
o > systems. Of course, it's also a lot cooler for some of us to just install
o > sshfs and make it work without spending too much time. This drawback could
o > probably be addressed by having a separate category (something called
o > 'kernel' for example) where we'd warn users that they can mess their systems
o > up if they don't know what they're doing.
o > 
o > My first question is wether we want kexts in MacPorts at once. FUSE would be
o > a fine addition then, we could also add something like a tun/tap device. If
o > we are to just distribute the userland stuff, it's going to be harder to get
o > users to update their kexts to match the userland libs versions.
o -- 
o Kevin Ballard
o eridius at

More information about the macports-dev mailing list