I don't see how this is specific to unified builds. It should be for all boards, but you need to ensure your config stuff is supported for those other platforms. Otherwise, you'll be putting a whole bunch of divergent pieces throughout system which seems wrong.

OK. That expands the scope of this bug somewhat but I think it is feasible. Will take a look once I have reduced my bug backlog

I don't think that we can--realistically--completely deprecate mosys. Instead, as proposed on Charles' V2 doc here: https://docs.google.com/document/d/1b4UexDvdI5-AKlPDldhz13_vJvpYr0bnkioXLntKbhU/edit#heading=h.2525wnhiigf1 , I think that mosys should continue to exist as the gateway to platform-specific hardware access to VPD, SMBIOS, SKU pins, etc.

I understand that there's a visceral desire to not have cros_config running a subprocess to access hardware when it could just do it itself.

To compromise, I propose that we export a shared library installed in the mosys build that allows cros_config to link in the hardware access capability without having to call 
mosys through a subprocess or a brittle stdin/stout API. This way, the platform-specific logic continues be owned by mosys and cros_config can focus on its config role.

That's not my objection.  It's having mosys read/use the config.

cros_config can solve this through config and hitting mosys and clients can dep on cros_config only

Yes, I agree, we want to separate concerns between cros_config and mosys. To do that, we have to agree on what those concerns are and whether cros_config and mosys continue to exist. Once we agree on that, we can work toward separation. Let's use this bug to work through agreement there.

Your objection to the coupling on https://chromium-review.googlesource.com/c/chromiumos/platform/mosys/+/692476/4 is valid but I think we can avoid the coupling problem right now for a different reason: I'm not sure the SKU Map in mosys is going to work as written for the reason that adurbin@ raised on that CL and you raised on https://chromium-review.googlesource.com/c/chromiumos/platform/mosys/+/692476/3/lib/cros_config/cros_config.c#108. Going to update that CL now more on that topic.

There are 2 issues:

1. you need mosys to answer the root question of 'where do i get my table of identifiers so a model name can be spit out?'
2. firmwareupdate uses mosys model for determining keys and images. 

#2 is by definition dependent on #1.

There could be more. I'm not sure what we'd encounter on the arm platforms.

Adding notes from offline discussion.

The CL's that precipitated this bug being opened brought the SKU Map from the cros_config into mosys to deduplicate the brand information: now, updating the config causes the built mosys to understand how to map a SKU to a brand string. The business reason that mosys contains this brand command--historically--is things like the ECHO server that manage the promotions for new CB's.

I think we all agree that brand should not live in mosys: this is a configuration problem that can (and should) be subsumed by cros_config.

Further, finding the few places that call "mosys platform brand" and, instead, migrating them to call cros_config is a tractable problem with a medium turn-around. As soon as that's done, we can drop the configuration embedded in mosys.

Can we retitle this bug to track removing the "mosys platform brand" command from unified builds? We'd remove cros_config embedding in mosys at the same time.

The bit i'm confused on is why there is pressure to build the bridge in the first place when we all pretty much agree on the final solution and are going to do that anyway in the next few weeks.

I don't yet have a good scope statement on all of the places that call the brand command. As soon as we have that, I think we could start talking about tradeoffs. I can work on that next week.

First off I plan to do the follow-on CL for mosys to support reef-uni, to address complaints on the first lot of CLs.

After that and Jason's sally into brand I think we might get a clearer idea of the best path.

Uses of "platform brand":

* cr50 test: http://cs/chromeos_public/src/third_party/autotest/files/server/cros/faft/cr50_test.py?l=247&rcl=3ae6e8ba53fc454025fa33f262385c6d71d5cb60
* used to set cr50 board ID based on brand: http://cs/chromeos_public/src/third_party/chromiumos-overlay/chromeos-base/chromeos-cr50-scripts/files/cr50-set-board-id.sh?l=90&rcl=b414cb95d6fc925f9ee7e85a170b607c765ae8f4
* cr50 autotest: http://cs/chromeos_public/src/third_party/autotest/files/server/site_tests/firmware_Cr50SetBoardId/firmware_Cr50SetBoardId.py?l=23&rcl=3ae6e8ba53fc454025fa33f262385c6d71d5cb60
* displayed on login screen: https://cs.corp.google.com/chromeos_public/src/platform2/login_manager/init/scripts/write-machine-info?q=%22platform+brand%22&sq=package:%5Echromeos&l=22&dr=C
* part of a factory test: http://cs/chromeos_public/src/platform/factory/py/test/pytests/model_sku.py?l=41&rcl=e5c0f87babfe794979a8de3cd525db1982556627

I suspected to find a use in something like UMA or UpdateEngine but, so far, haven't seen anything like that.

Additionally, as of today's CL's, Simon has added "platform name" to the list of commands that are relying on DTSI. See:

https://chromium-review.googlesource.com/c/chromiumos/platform/mosys/+/717259

I approved these because the name command blocked Robo.

We'll need to revert this out and have mosys provide this information from a source that is not DTSI so as to decouple from cros-config's underlying configuration information.

Taking this. I will chat with folks next week to come up with a strategy to move forward.

I think the best approach is to have mosys return the raw 'identify' (such as SKU ID, SMBIOS name, VPD info) and have cros_config look up the model.

For now we still need mosys to return the correct model, since not everything uses cros_config. Once we have got rid of 'mosys platform model' and the like, we can remove the code from mosys.

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

commit 269ae9589929150a9c0568a37e31e2d48ef045a6
Author: Simon Glass <sjg@chromium.org>
Date: Sun Oct 29 01:08:46 2017

chromeos-config: Add support for decoding SKU tables

At present mosys decodes the SKU table and provides us with a model name.
This is a useful feature since lots of things use mosys at present.
However we do want to move away from using mosys for identity at some
point.

On the other hand we don't necessarily want to read from SMBIOS tables and
VPD in cros_config. A reasonable compromise is to have mosys provide the
raw identity information (platform name and SKU ID) and cros_config to use
that to find the model. This has the advantage that we can support
determining the submodel and anything else we want to do with the
information.

To this end, implement SKU map decoding in cros_config. This is so far not
plumbed in. That (and tests) comes in a later CL.

BUG=chromium:777725, chromium:770768 
CQ-DEPEND=CL:737802
TEST=FEATURES=test emerge-reef-uni --nodeps chromeos-config-tools
(which really just tests that it builds)

Change-Id: I3e95ed8a0906c06f398e3b4410f7993f19dc13ab
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/739398
Reviewed-by: Jason Clinton <jclinton@chromium.org>

[add] https://crrev.com/269ae9589929150a9c0568a37e31e2d48ef045a6/chromeos-config/libcros_config/lookup.cc
[modify] https://crrev.com/269ae9589929150a9c0568a37e31e2d48ef045a6/chromeos-config/chromeos-config.gyp
[modify] https://crrev.com/269ae9589929150a9c0568a37e31e2d48ef045a6/chromeos-config/libcros_config/cros_config.cc
[modify] https://crrev.com/269ae9589929150a9c0568a37e31e2d48ef045a6/chromeos-config/libcros_config/cros_config.h

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

commit 9c439fbbef27ed69764a97515ef6c07cc9253950
Author: Jason D. Clinton <jclinton@chromium.org>
Date: Sun Feb 11 16:46:41 2018

chromeos-config: Remove last linkage to mosys

This will resolve a long-standing bug:  chromium:770768 .

BUG= chromium:770768 
TEST=FEATURES=test emerge-reef chromeos-config-tools

Change-Id: I2de48bfc21524d90c406837762bde1e7e0973c77
Reviewed-on: https://chromium-review.googlesource.com/912319
Tested-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Queue: Jason Clinton <jclinton@chromium.org>

[modify] https://crrev.com/9c439fbbef27ed69764a97515ef6c07cc9253950/chromeos-config/libcros_config/cros_config_common.cc
[modify] https://crrev.com/9c439fbbef27ed69764a97515ef6c07cc9253950/chromeos-config/libcros_config/cros_config.h

cros-config no longer depends on mosys.

mosys and cros-config use the same hardware interfaces to derive the information that they need.