Use RE string pattern matching for blacklist strings.

gpu/config/gpu_control_list_format.txt

 // Copyright (c) 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // A valid gpu control list json file is in the format of
 // {
 //   "version": "x.y",
 //   "entries": [
 //     { // entry 1
 //     },
@@ skipping 14 matching lines @@
 // 4. "device_id" is an array of strings.  0 is reserved.
 // 5. "multi_gpu_style" is a string, valid values include:
 //      a) "optimus": NVIDIA dual GPU
 //      b) "amd_switchable": AMD dual GPU
 //      c) "amd_switchable_integrated": AMD dual GPU, integrated GPU is active
 //      d) "amd_switchable_discrete": AMD dual GPU, discrete GPU is active
 //    c) and d) are only valid on Win, as on Mac we can switch GPU on the fly.
 // 6. "multi_gpu_category" is a string, valid values include "any", "primary",
 //    "secondary", and "active". If unspecified, the default value is "primary".
 //    See gpu_control_list.h for more details on the meanings of the strings.
-// 7. "driver_vendor" is a STRING structure (defined below).
+// 7. "driver_vendor" is a string pattern.
 // 8. "driver_version" is a VERSION structure (defined below).
 // 9. "driver_date" is a VERSION structure (defined below).
 //    The version is interpreted as "year.month.day".
 // 10. "gl_type" is a string, valid values include "gl", "gles", and "angle".
 //    If "gl_version" is specified and "gl_type" is not, use the default value.
 //    The default value on Android is "gles", on Windows is "angle", on other
 //    platforms is "gl".
 // 11. "gl_version" is a VERSION structure (defined below).
-// 12. "gl_vendor" is a STRING structure (defined below).
-// 13. "gl_renderer" is a STRING structure (defined below).
-// 14. "gl_extensions" is a STRING structure (defined below).
+// 12. "gl_vendor" is a string pattern.
+// 13. "gl_renderer" is a string pattern.
+// 14. "gl_extensions" is a string pattern.
 // 15. "perf_graphics" is a FLOAT structure (defined below).
 // 16. "perf_gaming" is a FLOAT structure (defined below).
 // 17. "perf_overall" is a FLOAT structure (defined below).
-// 18. "machine_model_name" is an array of strings.  The strings can contain
-//     any characters.
+// 18. "machine_model_name" is an array of string patterns.
 // 19. "machine_model_version" is a VERSION structure (defined below).
 // 20. "gpu_count" is a INT structure (defined below).
-// 21  "cpu_info" is a STRING structure (defined below).
+// 21  "cpu_info" is a string pattern.
 // 22. "exceptions" is a list of entries.
 // 23. "features" is a list of gpu control list options, which can be
 //     configured by a specific list. See its *_json.cc file for a list of
 //     supported features. This field is mandatory.
 // 24. "description" has the description of the entry.
 // 25. "webkit_bugs" is an array of associated webkit bug numbers.
 // 26. "cr_bugs" is an array of associated webkit bug numbers.
 // 27. "disabled" is a boolean. If it is present, the entry will be skipped.
 //     This can not be used in exceptions.
 // 28. "direct_rendering" is a boolean. If present, this will filter on whether
 // the GL contexts are direct or indirect based on the value.
 //
 // VERSION includes "op", "style", "value", and "value2".  "op" can be any of
 // the following values: "=", "<", "<=", ">", ">=", "any", "between".  "style"
 // is optional and can be "lexical" or "numerical"; if it's not specified, it
 // defaults to "numerical".  "value2" is only used if "op" is "between".
 // "between" is "value <= * <= value2".
 // "value" is used for all "op" values except "any". "value" and "value2"
 // are in the format of x, x.x, x.x.x, etc.
 // Only "driver_version" supports lexical style if the format is major.minor;
 // in that case, major is still numerical, but minor is lexical. 
 //
-// STRING includes "op" and "value".  "op" can be any of the following values:
-// "contains", "beginwith", "endwith", "=".  "value" is a string.
-//
 // FLOAT includes "op" "value", and "value2".  "op" can be any of the
 // following values: "=", "<", "<=", ">", ">=", "any", "between".  "value2" is
 // only used if "op" is "between".  "value" is used for all "op" values except
 // "any". "value" and "value2" are valid float numbers.
 // INT is very much like FLOAT, except that the values need to be integers.
-
+//
+// String pattern syntax can be found at
+// https://code.google.com/p/re2/wiki/Syntax.

[Ken Russell (switch to Gerrit), 2014/08/09 00:57:02]

As mentioned above, a tighter definition of how the matching is done is needed.
I'm pretty sure it isn't correct in all cases to simply convert a regexp pattern
to lower case via ASCII rules. At a minimum, it needs to be documented that both
the string pattern, and the value it matches against, are converted to lower
case. Perhaps it would be better to just use re's functionality for doing
case-insensitive matches. This would mean that all of the regexps would need to
be prefixed with (I think)

  (?i:re)

This would certainly make the various blacklists more verbose, so it's your
decision what to do here.

[Zhenyao Mo, 2014/08/09 01:23:59]

I think allow the full power of RE is a better option. However, we don't need to
set all entries to be case insensitive.  I think many of them should be
case-sensitive matching.  Only one needs to be case insensitive.