@xiyuan would you be able to guide Niranjan though this as a next learning CL? It's a fairly contained tidy up, but good intro to some of the areas involved in the startup flow.

+drcrash we did discuss the possibility we'll need this feature longer term (for kiosk mode auto enrolment) 
(even if we don't, it's a useful cleanup to make in the interim)

per f2f conversation, assign to niranjan@ with xiyuan@ to guide it

Yes that's a great idea. A /etc/chrome.conf would be great, and this would be read before /etc/chrome_dev.conf so that the latter could override the former (with care taken maybe to ensure that there is also a way to reset vmodule to the default in /etc/chrome_dev.conf even if one cannot touch a read-only /etc/chrome.conf).

I'm not supportive of adding a static /etc/chrome.conf file for specifying flags. Here's what I wrote over email:

----

The chrome_dev.conf stuff was added to permit developers to add or remove flags on live development devices. As background, there used to be a shell script that launched Chrome, but it didn't have tests and got way too complicated. When moving it to unit-tested C++ code, chrome_dev.conf was added to support developer needs.

We've been putting permanent flags in chrome_setup.cc (and chromium_command_builder.cc, if they're common to all Chromium-derived binaries rather than just the web browser) so far. It looks like that's already done for all the Rialto flags; what's the reason for switching it? Overlay-installed chrome.conf files seem much less flexible -- many flags need to be conditionally set or have their values be computed dynamically, which isn't possible with static config files.

----

It sounds like the main reason for this is that you'll soon need to set flags across multiple boards, right? If you're worried about needing to hardcode all these board names in chrome_setup.cc, you should just do what we usually do for this sort of thing: add a "rialto" USE flag and then check for that in chrome_setup.cc. That's what we already do for all the other flags that need to be set conditionally based on characteristics that are shared across multiple boards.

I really don't see any benefits to adding a /etc/chrome.conf file that gets installed from a bsp package. It's an inflexible, hardcoded list and it doesn't help as soon as you need to e.g. set additional flags for a variant (which is a common thing to do). USE flags seem like a better way of doing this.

The immediate motivation is not that we anticipate new 'railto-like' boards being added, but that the set of flags that need to be set are going to change a number of times as rialto migrates to kiosk mode. More details are in https://bugs.chromium.org/p/chromium/issues/detail?id=609968#c2   
(I should have linked that in the first place)

Thanks for clarifying. I don't understand why needing to change the flags affects this, though -- are there practical differences between changing chrome_setup.cc vs. changing a config file in an overlay? If modifying chrome_setup.cc is more onerous for some reason, I'd like to address that. (I'll note that modifying session_manager doesn't require manually bumping revision numbers on ebuild symlinks. :-P)

My larger point is that we'll always need to carry at least some flags in chrome_setup.cc, and I don't see many benefits to moving some of them to config files that live in different repositories.

The intention is to have a way to customize chrome switches for certain boards. Both use flag way and overlay-installed file works.

The bug started to propose using an overlay file. The reasoning is in #0, "something more flexible that doesn't require a session_manager CL for every flag change". But it sounds like that Dan actually prefers to change session manager code to keep everything in one place, and "use" flag is already used in session manager. Let's follow his suggestions. So the exiting workaround code would be changed to bind with a use flag and becomes the official code. :p

per https://bugs.chromium.org/p/chromium/issues/detail?id=640721 one of the flags that will need to be set is override the OEM manifest location, e.g. 

if (USE=rialto) {
  AddFalg("--app-mode-oem-manifest=/some-overlay-defined-location/manifest.json")
  ...
}

having the overlay both define the location of its manifest and configure the location that chrome will look for it, via the chrome.conf file, seemed cleaner that splitting this knowledge into two places (overlay creates file / login_manager knows where to find it).
Would there be a better way to set this?

(We can't use the default manifest location of /usr/share/oem/oobe/manifest.json for reasons explained in https://bugs.chromium.org/p/chromium/issues/detail?id=609968#c3)

No, I'm afraid not. I've wished before that it were possible for USE flags to carry values, but they're just boolean on/off.

Installing to paths specified in ebuild files and then hardcoding the same paths in code is unavoidable: even if a new chrome.conf file were introduced, "/etc/chrome.conf" would be duplicated across the overlays that installed it and the code in chrome_setup.cc that'd read it. :-P

The manifest path would still be duplicated too; both spots would just be in the overlay instead of one being in the login_manager repo instead. And the default /usr/share/oem/oobe/manifest.json path is already hardcoded in Chrome as well -- see chromeos/system/statistics_provider.cc.

thinking about this the simplest approach (and very consistent with many standard linux packages) would be to introduce a fallback system path, not controlled by any flag.

e.g.

  if (FileExists(usr/share/oem/oobe/manifest.json)) {
    LoadManifest(usr/share/oem/oobe/manifest.json)
+ else if (FileExists(/etc/default_oobe_manifest.json)) {
+   LoadManifest(/etc/default_oobe_manifest.json)
  }

That was the whole idea behind /etc/chrome.conf, right?

#12: Yes, that sounds reasonable to me too. I think that we do similar things in other places (e.g. OEM wallpaper).

#13: I don't follow. The /etc/chrome.conf proposal was about setting flags. It doesn't seem related to looking for an OEM-provided manifest file before falling back to a default one.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/overlays/overlay-variant-veyron-rialto-private/+/4132fe0341699837ff7238884f5ffc0ecf6acd9b

commit 4132fe0341699837ff7238884f5ffc0ecf6acd9b
Author: Niranjan Kumar <kumarniranjan@chromium.org>
Date: Wed Aug 24 21:21:14 2016

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/overlays/overlay-variant-veyron-rialto-private/+/4132fe0341699837ff7238884f5ffc0ecf6acd9b

commit 4132fe0341699837ff7238884f5ffc0ecf6acd9b
Author: Niranjan Kumar <kumarniranjan@chromium.org>
Date: Wed Aug 24 21:21:14 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/986f58425de0450e1607c28662f55561bd509105

commit 986f58425de0450e1607c28662f55561bd509105
Author: Niranjan Kumar <kumarniranjan@chromium.org>
Date: Thu Aug 25 19:40:58 2016

Add Rialto use flag

Put rialto use flag in the ebuild file.

BUG= chromium:638431 
TEST=built code, flashed to Rialto, verified that it works
Was able to successfully sync device.

Change-Id: I914c1a3689219b959c5ee48b26d10d379d509b78
Reviewed-on: https://chromium-review.googlesource.com/376139
Commit-Ready: Niranjan Kumar <kumarniranjan@chromium.org>
Tested-by: Niranjan Kumar <kumarniranjan@chromium.org>
Reviewed-by: Dan Erat (ooo friday) <derat@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>

[rename] https://crrev.com/986f58425de0450e1607c28662f55561bd509105/chromeos-base/libchromeos-use-flags/libchromeos-use-flags-0.0.1-r15.ebuild
[modify] https://crrev.com/986f58425de0450e1607c28662f55561bd509105/chromeos-base/libchromeos-use-flags/libchromeos-use-flags-0.0.1.ebuild

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/6dd853b0bd0f6b82d115541333be14ec2a84dec1

commit 6dd853b0bd0f6b82d115541333be14ec2a84dec1
Author: Niranjan Kumar <kumarniranjan@chromium.org>
Date: Wed Aug 24 21:46:08 2016

login: Accept rialto use flag

If rialto use flag is detected, supply
rialto-specific arguments to Chromium browser
during startup.

CQ-DEPEND=CL:376139
BUG= chromium:638431 
TEST=built code, flashed to Rialto, verified that it works
Was able to successfully sync device.

Change-Id: I9f4e4daca3003e9fd8f667555cc388487d415852
Reviewed-on: https://chromium-review.googlesource.com/375358
Commit-Ready: Niranjan Kumar <kumarniranjan@chromium.org>
Tested-by: Niranjan Kumar <kumarniranjan@chromium.org>
Reviewed-by: Dan Erat (ooo friday) <derat@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>

[modify] https://crrev.com/6dd853b0bd0f6b82d115541333be14ec2a84dec1/login_manager/chrome_setup.cc