Encoding Device Type Proposal

[Jacob]

Currently, determining the type of ChromeOS device we are on (Chromebit, Chromebase, Chromebook, Chromebox) is done by mapping the board name to the device. This map is hard-coded and needs to be updated whenever a new board is released/created.

Instead, the device type can be added to /etc/lsb_release which will will be baked into the device. The device-type mapping will still have to exist for old Chrome devices which do not have the updated metadata inside of /etc/lsb_release, but it will no longer need to be updated for each new board.

Thoughts?

Context:

crbug.com/341356

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/chromeos/chromeos_utils.cc&l=53

[Bertrand Simonnet]

You can also use the /etc/os-release.d mechanism to do set this field.

The good thing about this is that you can set it in an ebuild (bsp ebuild for example) without file conflict as each field is a single file.

See:

* https://cs.corp.google.com/#chromeos_public/src/third_party/chromiumos-overlay/eclass/osreleased.eclass

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Mukesh Agrawal]

I might be missing something here, but... Chrome is baked into the ChromeOS image, right? So if we update lsb-release for all boards in M-45 (e.g.), then can't we drop the mapping code from Chrome in M-45 as well? (Is there a reason _not_ to update lsb_release for existing boards?)

[Mike Frysinger]

right, i don't understand the statement "old Chrome device which do not have the update".  there is no such thing in Chrome OS land.

-mike

[Gaurav Shah]

The mapping has to be *somewhere*. If this info is going to be a part of the /etc/lsb-release, then you need a way to do this at build time. We have precedence for doing board-specific /etc/lsb-release mangling (search for "doappid" on code search).

Another alternative (that is also discussed in the bug) is to have this be encoded as part of the VPD (just like we do with the HWID). This would require this info to be baked at factory time. This will obviously not work for existing devices.

-g

On Wed, May 20, 2015 at 3:21 PM, Jacob <jduf...@chromium.org> wrote:

[Mukesh Agrawal]

IIRC, +Paul Stewart argued against putting such information in VPD, since the value is the same for all units of a given board. (Compare with, e.g., "region". "region" will vary for different units of the same board.)

[Chris Sosa]

On Wed, May 20, 2015 at 5:56 PM, Mukesh Agrawal <qui...@chromium.org> wrote:

IIRC, +Paul Stewart argued against putting such information in VPD, since the value is the same for all units of a given board. (Compare with, e.g., "region". "region" will vary for different units of the same board.)

On Wed, May 20, 2015 at 5:51 PM Gaurav Shah <gaur...@chromium.org> wrote:

The mapping has to be *somewhere*. If this info is going to be a part of the /etc/lsb-release, then you need a way to do this at build time. We have precedence for doing board-specific /etc/lsb-release mangling (search for "doappid" on code search).

+1 adding a "dofriendlyname" method similar to doappid,dohwid which results in a friendly string in /etc/lsb-release. These can be used in the bsp in the given overlay. The harder part is enforcing it actually gets set by folks and making sure it stays consistent with what you expect i.e. I'd expect it to get stale just like a mapping somewhere else might.

-Sosa 

 

Another alternative (that is also discussed in the bug) is to have this be encoded as part of the VPD (just like we do with the HWID). This would require this info to be baked at factory time. This will obviously not work for existing devices.

-g

On Wed, May 20, 2015 at 3:21 PM, Jacob <jduf...@chromium.org> wrote:

Currently, determining the type of ChromeOS device we are on (Chromebit, Chromebase, Chromebook, Chromebox) is done by mapping the board name to the device. This map is hard-coded and needs to be updated whenever a new board is released/created.

Instead, the device type can be added to /etc/lsb_release which will will be baked into the device. The device-type mapping will still have to exist for old Chrome devices which do not have the updated metadata inside of /etc/lsb_release, but it will no longer need to be updated for each new board.

Thoughts?

Context:

crbug.com/341356

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/chromeos/chromeos_utils.cc&l=53

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Jacob Dufault]

> I might be missing something here, but... Chrome is baked into the ChromeOS image, right? So if we update lsb-release for all boards in M-45 (e.g.), then can't we drop the mapping code from Chrome in M-45 as well? (Is there a reason _not_ to update lsb_release for existing boards?)

> right, i don't understand the statement "old Chrome device which do not have the update".  there is no such thing in Chrome OS land.

Oops - I mistakenly assumed that /etc/lsb-release was baked in the factory. There shouldn't be any need to keep the existing mapping code then.

Since there is pushback on adding info to the vpd (and since we will have to maintain the mapping code for old devices), I'll add the board-info to /etc/lsb-release. There is already some infrastructure in place (that I could find) to read from /etc/lsb-release, which makes me prefer it over /etc/os-release.d. I'll start working on a script similar to doappid - thanks!