Pull seccomp-sandbox in via DEPS rather than using an in-tree copy...

Pull seccomp-sandbox in via DEPS rather than using an in-tree copy 

This means changes to the sandbox won't have to be committed twice, to 
both trees. 

This is a retry of r57921, which was committed with git-svn and failed 
to remove the "seccomp" directory. This caused problems when trying 
to "svn checkout" to the same location, and the change was reverted. 
This time I will use SVN to commit the change. 

BUG=none 
TEST=smoke test of running chromium with --enable-seccomp-sandbox 

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=58184

[Mark Seaborn, 2010-08-31 08:13:40]

Unfortunately Rietveld does not show that, this time, I did "svn rm
sandbox/linux/seccomp" -- it doesn't show that the directories are supposed to
be removed.

[Markus (顧孟勤), 2010-08-31 08:59:41]

LGTM

[Nicolas Sylvain, 2010-08-31 16:02:45]

You are still not deleting the tests files under seccomp.

I'd really prefer if you can find another directory though. svn del is not
perfect, and often leaves temp files around. This require manual clobber on
all machines.  Repurposing a svn dir to a gclient fetch dir is actually not
something our workflow supports.

(This caused the tree to be closed for about 4 hours yesterday afternoon)

If you are confident that svn del works and delete the whole seccomp
directory, then ok...

also don't forget to add the svn:ignore on the sandbox/linux directory


On Tue, Aug 31, 2010 at 1:13 AM, <mseaborn@chromium.org> wrote:

> Reviewers: Markus (顧孟勤), Nicolas Sylvain,
>
> Message:
> Unfortunately Rietveld does not show that, this time, I did "svn rm
> sandbox/linux/seccomp" -- it doesn't show that the directories are supposed
> to
> be removed.
>
> Description:
> Pull seccomp-sandbox in via DEPS rather than using an in-tree copy
>
> This means changes to the sandbox won't have to be committed twice, to
> both trees.
>
> This is a retry of r57921, which was committed with git-svn and failed
> to remove the "seccomp" directory.  This caused problems when trying
> to "svn checkout" to the same location, and the change was reverted.
> This time I will use SVN to commit the change.
>
> BUG=none
> TEST=smoke test of running chromium with --enable-seccomp-sandbox
>
>
> Please review this at http://codereview.chromium.org/3225010/show
>
> SVN Base: svn://svn.chromium.org/chrome/trunk/src/
>
> Affected files:
>  M     DEPS
>  D     sandbox/linux/seccomp/Makefile
>  D     sandbox/linux/seccomp/access.cc
>  D     sandbox/linux/seccomp/allocator.h
>  D     sandbox/linux/seccomp/allocator.cc
>  D     sandbox/linux/seccomp/clone.cc
>  D     sandbox/linux/seccomp/debug.h
>  D     sandbox/linux/seccomp/debug.cc
>  D     sandbox/linux/seccomp/exit.cc
>  D     sandbox/linux/seccomp/getpid.cc
>  D     sandbox/linux/seccomp/gettid.cc
>  D     sandbox/linux/seccomp/ioctl.cc
>  D     sandbox/linux/seccomp/ipc.cc
>  D     sandbox/linux/seccomp/library.h
>  D     sandbox/linux/seccomp/library.cc
>  D     sandbox/linux/seccomp/linux_syscall_support.h
>  D     sandbox/linux/seccomp/madvise.cc
>  D     sandbox/linux/seccomp/maps.h
>  D     sandbox/linux/seccomp/maps.cc
>  D     sandbox/linux/seccomp/mmap.cc
>  D     sandbox/linux/seccomp/mprotect.cc
>  D     sandbox/linux/seccomp/munmap.cc
>  D     sandbox/linux/seccomp/mutex.h
>  D     sandbox/linux/seccomp/open.cc
>  D     sandbox/linux/seccomp/sandbox.h
>  D     sandbox/linux/seccomp/sandbox.cc
>  D     sandbox/linux/seccomp/sandbox_impl.h
>  D     sandbox/linux/seccomp/seccomp.gyp
>  D     sandbox/linux/seccomp/securemem.h
>  D     sandbox/linux/seccomp/securemem.cc
>  D     sandbox/linux/seccomp/sigaction.cc
>  D     sandbox/linux/seccomp/sigprocmask.cc
>  D     sandbox/linux/seccomp/socketcall.cc
>  D     sandbox/linux/seccomp/stat.cc
>  D     sandbox/linux/seccomp/syscall.h
>  D     sandbox/linux/seccomp/syscall.cc
>  D     sandbox/linux/seccomp/syscall_table.h
>  D     sandbox/linux/seccomp/syscall_table.c
>  D     sandbox/linux/seccomp/tests/list_tests.py
>  D     sandbox/linux/seccomp/tests/test_syscalls.cc
>  D     sandbox/linux/seccomp/timestats.cc
>  D     sandbox/linux/seccomp/tls.h
>  D     sandbox/linux/seccomp/trusted_process.cc
>  D     sandbox/linux/seccomp/trusted_thread.cc
>  D     sandbox/linux/seccomp/x86_decode.h
>  D     sandbox/linux/seccomp/x86_decode.cc
>
>
>

[Nicolas Sylvain, 2010-08-31 16:03:49]

On Tue, Aug 31, 2010 at 9:02 AM, Nicolas Sylvain <nsylvain@chromium.org>wrote:

> You are still not deleting the tests files under seccomp.
>
> I'd really prefer if you can find another directory though. svn del is not
> perfect, and often leaves temp files around. This require manual clobber on
> all machines.  Repurposing a svn dir to a gclient fetch dir is actually not
> something our workflow supports.
>
> (This caused the tree to be closed for about 4 hours yesterday afternoon)
>
> If you are confident that svn del works and delete the whole seccomp
> directory, then ok...
>
> also don't forget to add the svn:ignore on the sandbox/linux directory
>
>
> On Tue, Aug 31, 2010 at 1:13 AM, <mseaborn@chromium.org> wrote:
>
>> Reviewers: Markus (顧孟勤), Nicolas Sylvain,
>>
>> Message:
>> Unfortunately Rietveld does not show that, this time, I did "svn rm
>> sandbox/linux/seccomp" -- it doesn't show that the directories are
>> supposed to
>> be removed.
>>
> Can you paste the output of svn status from the sandbox directory^

thanks



>
>> Description:
>> Pull seccomp-sandbox in via DEPS rather than using an in-tree copy
>>
>> This means changes to the sandbox won't have to be committed twice, to
>> both trees.
>>
>> This is a retry of r57921, which was committed with git-svn and failed
>> to remove the "seccomp" directory.  This caused problems when trying
>> to "svn checkout" to the same location, and the change was reverted.
>> This time I will use SVN to commit the change.
>>
>> BUG=none
>> TEST=smoke test of running chromium with --enable-seccomp-sandbox
>>
>>
>> Please review this at http://codereview.chromium.org/3225010/show
>>
>> SVN Base: svn://svn.chromium.org/chrome/trunk/src/
>>
>> Affected files:
>>  M     DEPS
>>  D     sandbox/linux/seccomp/Makefile
>>  D     sandbox/linux/seccomp/access.cc
>>  D     sandbox/linux/seccomp/allocator.h
>>  D     sandbox/linux/seccomp/allocator.cc
>>  D     sandbox/linux/seccomp/clone.cc
>>  D     sandbox/linux/seccomp/debug.h
>>  D     sandbox/linux/seccomp/debug.cc
>>  D     sandbox/linux/seccomp/exit.cc
>>  D     sandbox/linux/seccomp/getpid.cc
>>  D     sandbox/linux/seccomp/gettid.cc
>>  D     sandbox/linux/seccomp/ioctl.cc
>>  D     sandbox/linux/seccomp/ipc.cc
>>  D     sandbox/linux/seccomp/library.h
>>  D     sandbox/linux/seccomp/library.cc
>>  D     sandbox/linux/seccomp/linux_syscall_support.h
>>  D     sandbox/linux/seccomp/madvise.cc
>>  D     sandbox/linux/seccomp/maps.h
>>  D     sandbox/linux/seccomp/maps.cc
>>  D     sandbox/linux/seccomp/mmap.cc
>>  D     sandbox/linux/seccomp/mprotect.cc
>>  D     sandbox/linux/seccomp/munmap.cc
>>  D     sandbox/linux/seccomp/mutex.h
>>  D     sandbox/linux/seccomp/open.cc
>>  D     sandbox/linux/seccomp/sandbox.h
>>  D     sandbox/linux/seccomp/sandbox.cc
>>  D     sandbox/linux/seccomp/sandbox_impl.h
>>  D     sandbox/linux/seccomp/seccomp.gyp
>>  D     sandbox/linux/seccomp/securemem.h
>>  D     sandbox/linux/seccomp/securemem.cc
>>  D     sandbox/linux/seccomp/sigaction.cc
>>  D     sandbox/linux/seccomp/sigprocmask.cc
>>  D     sandbox/linux/seccomp/socketcall.cc
>>  D     sandbox/linux/seccomp/stat.cc
>>  D     sandbox/linux/seccomp/syscall.h
>>  D     sandbox/linux/seccomp/syscall.cc
>>  D     sandbox/linux/seccomp/syscall_table.h
>>  D     sandbox/linux/seccomp/syscall_table.c
>>  D     sandbox/linux/seccomp/tests/list_tests.py
>>  D     sandbox/linux/seccomp/tests/test_syscalls.cc
>>  D     sandbox/linux/seccomp/timestats.cc
>>  D     sandbox/linux/seccomp/tls.h
>>  D     sandbox/linux/seccomp/trusted_process.cc
>>  D     sandbox/linux/seccomp/trusted_thread.cc
>>  D     sandbox/linux/seccomp/x86_decode.h
>>  D     sandbox/linux/seccomp/x86_decode.cc
>>
>>
>>
>

[Mark Seaborn, 2010-09-01 10:29:48]

On 31 August 2010 17:03, Nicolas Sylvain <nsylvain@chromium.org> wrote:

> On Tue, Aug 31, 2010 at 9:02 AM, Nicolas Sylvain <nsylvain@chromium.org>wrote:
>
>> You are still not deleting the tests files under seccomp.
>>
>
Yes I am: I'm deleting the whole seccomp directory.


> I'd really prefer if you can find another directory though. svn del is not
>> perfect, and often leaves temp files around. This require manual clobber on
>> all machines.  Repurposing a svn dir to a gclient fetch dir is actually not
>> something our workflow supports.
>>
>
Hmm, the problem with that is that it could leave pathnames as out-of-bounds
for gclient fetch dirs in perpetuity.  Suppose I remove
"sandbox/linux/seccomp" in SVN, and some time later it is turned into a
gclient fetch dir.  Anyone adding a new DEPS entry would potentially have to
check all the history in case an SVN dir lived at that location in the past.

(This caused the tree to be closed for about 4 hours yesterday afternoon)
>>
>
Sorry about that.  I didn't realise that git-svn had changed its behaviour
and no longer deleted directories.


> If you are confident that svn del works and delete the whole seccomp
>> directory, then ok...
>>
>> also don't forget to add the svn:ignore on the sandbox/linux directory
>>
>>
>> On Tue, Aug 31, 2010 at 1:13 AM, <mseaborn@chromium.org> wrote:
>>
>>> Reviewers: Markus (顧孟勤), Nicolas Sylvain,
>>>
>>> Message:
>>> Unfortunately Rietveld does not show that, this time, I did "svn rm
>>> sandbox/linux/seccomp" -- it doesn't show that the directories are
>>> supposed to
>>> be removed.
>>>
>> Can you paste the output of svn status from the sandbox directory^
>
> thanks
>

Sure:

mseaborn@chaparral:~/devel/chromium-svn/src/sandbox$ svn st
D      linux/seccomp
D      linux/seccomp/mprotect.cc
D      linux/seccomp/sandbox.h
D      linux/seccomp/maps.cc
D      linux/seccomp/clone.cc
D      linux/seccomp/open.cc
D      linux/seccomp/mutex.h
D      linux/seccomp/library.cc
D      linux/seccomp/exit.cc
D      linux/seccomp/ipc.cc
D      linux/seccomp/stat.cc
D      linux/seccomp/syscall.h
D      linux/seccomp/tests
D      linux/seccomp/tests/test_syscalls.cc
D      linux/seccomp/tests/list_tests.py
D      linux/seccomp/sigaction.cc
D      linux/seccomp/allocator.cc
D      linux/seccomp/sandbox_impl.h
D      linux/seccomp/sigprocmask.cc
D      linux/seccomp/socketcall.cc
D      linux/seccomp/securemem.cc
D      linux/seccomp/securemem.h
D      linux/seccomp/debug.h
D      linux/seccomp/madvise.cc
D      linux/seccomp/Makefile
D      linux/seccomp/mmap.cc
D      linux/seccomp/x86_decode.h
D      linux/seccomp/munmap.cc
D      linux/seccomp/sandbox.cc
D      linux/seccomp/access.cc
D      linux/seccomp/maps.h
D      linux/seccomp/seccomp.gyp
D      linux/seccomp/tls.h
D      linux/seccomp/library.h
D      linux/seccomp/ioctl.cc
D      linux/seccomp/syscall.cc
D      linux/seccomp/getpid.cc
D      linux/seccomp/timestats.cc
D      linux/seccomp/syscall_table.c
D      linux/seccomp/gettid.cc
D      linux/seccomp/trusted_thread.cc
D      linux/seccomp/allocator.h
D      linux/seccomp/syscall_table.h
D      linux/seccomp/debug.cc
D      linux/seccomp/linux_syscall_support.h
D      linux/seccomp/trusted_process.cc
D      linux/seccomp/x86_decode.cc

Mark

[Mark Seaborn, 2010-09-01 13:08:49]

On 31 August 2010 17:02, Nicolas Sylvain <nsylvain@chromium.org> wrote:

> You are still not deleting the tests files under seccomp.
>
> I'd really prefer if you can find another directory though. svn del is not
> perfect, and often leaves temp files around. This require manual clobber on
> all machines.  Repurposing a svn dir to a gclient fetch dir is actually not
> something our workflow supports.
>

OK, I have moved the gclient fetch dir to a top-level directory,
"src/seccompsandbox".  Only a small number of files needed changing to refer
to the new location.

This is probably a good thing to do anyway for when seccompsandbox is also
pulled in to the standalone Native Client build.  It will make it easier to
use the same #include path in both cases.


also don't forget to add the svn:ignore on the sandbox/linux directory
>

Done.  I have added an entry to svn:ignore on the top-level directory,
although it doesn't show up in Rietveld, and it also didn't seem to be
up-to-date (Breakpad was not on the list).  I have also updated .gitignore.

Cheers,
Mark

[nsylvain, 2010-09-01 13:50:56]

LGTM

src/breakpad does not need to be added to the svn:ignore because it is actually
a real directory. What we fetch is in 
src/breakpad/src

thanks