chroots for testing other OS versions

Jordan K. Hubbard jkh at apple.com
Mon Nov 21 12:19:06 PST 2011


Hi Paul,

Thank you very much for the additional historical information - very helpful!

I tend to concur with your conclusions.  it will be easier to to start with the MacPorts version, with all of its MacPorts-specific IPC, and just bring over the more modern interposing, so I'm going to pursue that option (it's a nice side project and Apple gave us the week off for thanksgiving :) ).

I also agree that baking in the exception list vs having it passed in by the higher-level MacPorts code is an inferior approach and should not be brought across, though that list should be at least looked at and I will.  I think it's missing some of the more modern requirements for filesystem access.  The only issue that's still outstanding is Joshua's assertion that individual ports should be able to poke their own individual holes in the trace sandbox, and he hasn't elaborated on that yet but I'm guessing it might look something like this:

trace_exceptions	{ "/vol/.happyFile" "r+w" }  {"/usr/local/share/sharedfile" "r+a"}
...
trace_exceptions.append { "/some/other/file" "r" }

Though, ultimately, I would also hope that this kind of behavior would be discouraged and someday deprecated, once software on the platform becomes a bit less unruly (an evolutionary direction which the Mac App store is encouraging).

- Jordan

On Nov 21, 2011, at 9:40 AM, Paul Guyot wrote:

> Jordan,
> 
> If you look at the change logs here and there:
> http://trac.macports.org/log/trunk/base/src/darwintracelib1.0/darwintrace.c
> http://darwinbuild.macosforge.org/trac/log/trunk/darwintrace/darwintrace.c
> 
> you will see that the upstream version was synchronized at least twice.
> Latest being at MacPorts' revision 18667 against upstream's revision 255.
> 
> I have not committed this file since August, 2006 and therefore since any upstream change after revision 255. Upstream merges would have been done by someone else, if any.
> 
> Judging from changes between upstream r985 (HEAD) and r255, upstream brings "modern interposing" but also duplicates a feature of MacPorts' version with exceptions (a static list upstream, provided by the IPC for MacPorts). The IPC has been mostly developed by Eugene Pimenov during his GSoC internship.
> 
> At a quick glance, I would suggest porting MacPorts' version to use the newer API rather than try to rebase or start over. It is simpler, and the upstream code is now smaller than the MacPorts-specific logic. Besides, upstream is unlikely to include our (very-MacPorts specific) changes, especially since the communication between the lib and MacPorts was implemented to trace usage of each port.
> 
> FYI, I believe non-regression tests were developed and could prove helpful with the port.
> 
> Paul
> 
> Le 20 nov. 2011 à 23:13, Jordan K. Hubbard a écrit :
> 
>> Hmmm.  Is Paul (added to CC) still around, does anyone know? :)
>> 
>> I looked into fixing #29228 based on darwinbuild/darwintrace/darwintrace.c trunk, but it would help to know which version Paul started from since the divergence is significant!   Otherwise, I guess I'll just figure out the tracelib IPC and start over.   Just out of curiosity, what is the anticipated usage scenario for the 2nd bullet?  Is there another ticket tracking those requirements?  I might as well hit both while I'm in there...   The third bullet should be taken care of in 10.7, at least, by the newer darwintrace sources.
>> 
>> - Jordan
>> 
>> On Nov 18, 2011, at 2:08 PM, Joshua Root wrote:
>> 
>>> Things that need doing:
>>> 
>>> * modern interposing (#29228)
>>> * add a mechanism to allow flexibly specifying (globally and per-port)
>>> sets of files and how they should be treated, e.g. allow/deny for r/w/x
>>> * I suspect it may not wrap every function it should
>> 
> 
> -- 
> Semiocast            http://semiocast.com/
> +33.183627948 - 20 rue Lacaze, 75014 Paris
> 



More information about the macports-dev mailing list