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
>
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
