validator_ragel: Link into TCB, use under env var

src/trusted/service_runtime/sel_main_chrome.h

 /*
  * Copyright (c) 2012 The Native Client Authors. All rights reserved.
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #ifndef NATIVE_CLIENT_SRC_TRUSTED_SERVICE_RUNTIME_SEL_MAIN_CHROME_H_
 #define NATIVE_CLIENT_SRC_TRUSTED_SERVICE_RUNTIME_SEL_MAIN_CHROME_H_ 1
 
 #include "native_client/src/include/nacl_base.h"
@@ skipping 41 matching lines @@
   NaClBrokerDuplicateHandleFunc broker_duplicate_handle_func;
 
   /*
    * Callback to use for requesting that a debug exception handler be
    * attached to this process for handling hardware exceptions via the
    * Windows debug API.  The data in info/info_size must be passed to
    * NaClDebugExceptionHandlerRun().  Optional; may be NULL.
    */
   int (*attach_debug_exception_handler_func)(void *info, size_t info_size);
 #endif
+
+  /* Dangerous: replace the main validator with the new DFA-based validator. */
+  int enable_dfa_validator;

[Mark Seaborn, 2012/04/19 22:11:39]

I don't think this belongs here.  Chromium does not need to know about the
validators, so don't add this to NaClChromeMainArgs, please.

Using an env var is preferable.  If you want to add something to about:flags, we
can discuss that.

[pasko-google - do not use, 2012/04/19 22:36:27]

I do not have a strong preference on flag vs. env var for chrome. Can do either
way.

The env var seems to take less code because we can check for it in the deep
validator corners. On the other side, having all switches visible in one place
has it's advantages. Easier to review, less security risks, etc.

Reminds me of a story where engineers forgot to remove env var check deep in
their compiler, performed different optimization passes depending on $USER.

[Nick Bray, 2012/04/19 23:11:08]

In general, plumbing stuff from Chrome is a pain and using env vars to gate
experimental features helps keep things simple.  You probably want to keep the
check as high as possible, but modifying the browser interface seems excessive.

[pasko-google - do not use, 2012/04/20 14:30:38]

Yes, keeping the check high has the benefit of keeping it close to other similar
checks. So in one glance anyone can see what kind of things can be requested
from service_runtime when running in the browser. This serves as a good
self-documentation.

But yes, since it is an experimental/temporary feature it may be OK to go with
an environment variable check buried deep in the woods. I am doing that since
both you and Mark clearly expressed your preference.

 };
 
 /* Create a new args struct containing default values. */
 struct NaClChromeMainArgs *NaClChromeMainArgsCreate(void);
 
 /* Launch NaCl. */
 void NaClChromeMainStart(struct NaClChromeMainArgs *args);
 
 
 EXTERN_C_END
 
 #endif