Kernel extensions in MacPorts

Pierre Queinnec pmq at macports.org
Tue Jan 16 08:29:35 PST 2007


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 at macports.org <mailto:eridius at macports.org>
> http://www.tildesoft.com
> 
> 



More information about the macports-dev mailing list