Don't start the SECCOMP sandbox early for Tegra124

content/public/common/content_switches.cc

Index: content/public/common/content_switches.cc
diff --git a/content/public/common/content_switches.cc b/content/public/common/content_switches.cc
index ea4a1b36e1ed05e6bd5d3e6813ff0541716e7bda..b1fdbdca71d24a5268296e39e2afdf97add1eb2d 100644
--- a/content/public/common/content_switches.cc
+++ b/content/public/common/content_switches.cc
@@ -670,6 +670,9 @@ const char kGpuProcess[]                    = "gpu-process";
 // Allow shmat system call in GPU sandbox.
 const char kGpuSandboxAllowSysVShm[]        = "gpu-sandbox-allow-sysv-shm";
 
+// Allow GPU sandbox to start later
+const char kGpuSandboxStartLater[]          = "gpu-sandbox-start-later";

[Jorge Lucangeli Obes, 2014/03/19 16:44:05]

We should call this one something like "gpu-sandbox-delay-init".

[jln (very slow on Chromium), 2014/03/20 00:21:01]

It would be nice to make it clear that the "normal", expected behavior is the
one that NVidia is now following. I would prefer if Mali was the one that
requires a special "early initialization" flag.

Since it's not a trivial change, maybe a name such as
"gpu-sandbox-start-after-initialization" or the one Jorge suggested is ok in the
meantime.

But it'd be nice to reverse the polarity and have Mali use
"--do-sandbox-early-init-with-horrible-hacks-please-dont-use-me" at some point.

+
 // Causes the GPU process to display a dialog on launch.
 const char kGpuStartupDialog[]              = "gpu-startup-dialog";