I think this is a valid and useful extension of MP's mission. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University On Sun, 14 Jan 2007, Pierre Queinnec wrote: o Hi all, o o Eridius pointed me on IRC to MacFUSE, the recently released FUSE port to OS X. o 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 'kernel' o for example) where we'd warn users that they can mess their systems up if they o don't know what they're doing. o o My first question is wether we want kexts in MacPorts at once. FUSE would be a o fine addition then, we could also add something like a tun/tap device. If we o 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 Thoughts on this? o -- Pierre o _______________________________________________ o macports-dev mailing list o macports-dev@lists.macosforge.org o http://lists.macosforge.org/mailman/listinfo/macports-dev o o

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 smile. -------------- 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 o The biggest problem is, at least with the official release (I haven't tested o 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 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 o Perhaps I'll try contacting Amit Singh later to get his input on this. o 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@macports.org>. o o -Kevin Ballard a.k.a. Eridius o o On Jan 14, 2007, at 11:23 AM, Pierre Queinnec wrote: o 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 -- o Kevin Ballard o http://kevin.sb.org o eridius@macports.org o http://www.tildesoft.com o o

Hi Kevin, Sal, I have to say that I'd prefer MP to not load/unload the kexts for me. On wether the user knows or not how to unload the kernel extension, I think the problem should be made clear to the user when installing from the kernel category: some sort of "if you're feeling uncomfortable about this and/or don't know what you're doing, then stop". -- Pierre Kevin Ballard wrote:

I am of the opinion that not cleanly removing a kernel extension is far worse than not shutting down apache before installing it. Especially since it's a reasonable assumption that the user knows how to shut down apache before uninstalling, but it's not so reasonable an assumption that the user knows how to unload a kernel extension before uninstalling.

On Jan 15, 2007, at 12:21 PM, Salvatore Domenick Desiano wrote:

...

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.

-- Kevin Ballard http://kevin.sb.org eridius@macports.org <mailto:eridius@macports.org> http://www.tildesoft.com

On Jan 16, 2007, at 10:01 AM, Kevin Ballard wrote:

Possibly. I'd at least like to add a pre-deactivate hook that can query kextstat to see if the extension is loaded, and pop up a huge honking warning telling the user that this could be dangerous, and ask to continue? <y/n>.

I'd rather just add the FUSE kexts now, and worry about auto-loading them (or not) later. Personally I don't want DarwinPorts loading or unloading kexts automatically. There are all kinds of corner cases that are difficult to handle. -landonf

o > Possibly. I'd at least like to add a pre-deactivate hook that can query o > kextstat to see if the extension is loaded, and pop up a huge honking o > warning telling the user that this could be dangerous, and ask to continue? o > <y/n>. o o I'd rather just add the FUSE kexts now, and worry about auto-loading them (or o not) later. o Personally I don't want DarwinPorts loading or unloading kexts automatically. o There are all kinds of corner cases that are difficult to handle. Out of curiousity, what's the danger in uninstalling a loaded kernel module? -- Sal smile.