It's still their only for better "inheritance" of config particularly for the powerd where there could be many config files, not just one as it's elsewhere. On Coral it doesn't appear to be used in the end since the platforms are so similar and I was thinking of getting rid of it there (and because in its current form it's a bit of a hack), but the general issue should be addressed for future projects. Maybe the yaml/json stuff does it, but I haven't managed to try it out yet

Now that we have powerd support in unbuild ( crbug.com/709982 ), perhaps it is not needed?

Is it used for anything other than powerd?

Otherwise, I don't think this is blocked on the yaml conversion.

No, that's the point I was trying to make. If you don't want to copy a whole directory of config files from one model to the next because all you need is to add one more file or change one of the multiple files, what's there in UB is not cutting it 100%.

@patrick Which directory of config files are you referring to?

what goes into /usr/share/power_manager/model_specific/<model>/.
Imagine that modelA has 7 config files and modelB has the same 7 identical config files and just needs to add an 8th file (or override a setting in just one of those 7).

If I look at http://cs/chromeos_public/src/platform2/power_manager/common/power_constants.cc there's quite a few possibilities.

OK, but with unibuild support we don't need those files anymore. The settings can go directly in the master config.

I don't think that's a great solution unless you don't do validation of the properties and let pretty much anything go in there (which is not the approach generally taken in v1 at least).
- The Readme.md mentions a handful of possible properties, definitely much less than what powerd allows
- how would you keep in sync with powerd evolution over time when flags are added/removed?

This seems too tightly coupled to me or you'll somehow need to drill into powerd contributors that they need to also update chromeos-config, wisdom that over time probably will get lost.

+Lann, Ben

I think the current properties are the ones that seem to vary a lot from the defaults. If we want to support more, we need to add them to the schema. I suppose one day we could drop the ability to install files to create their settings, and then the master config would be the only means to do this. Then people would definitely keep things in sync.

But for now, my point is that we have support for this in the master config, so perhaps we don't need to install files? We could look at this for reef, for example, and see if it works out.

The current properties are the ones that reef used at the time: crrev.com/c/786074

> we have support for this in the master config, so perhaps we don't need to install files

I agree that for new projects that's a good way to go, but I'm not keen on seeing coral changed just because we can. There's always more to it than just checking something in on ToT

Starter paths here are:
https://cs.corp.google.com/chromeos_public/src/overlays/overlay-coral/chromeos-base/chromeos-config-bsp-coral/files/lava/model.dtsi?dr

Also, see the ref'd cl in comment #9

For general design context, see:
go/cros-config-mgmt-inc-design

First step here is to remove the powerd config files from the public BSP ebuild's files/ directory and put them in the master config instead. Then we should be able to drop the cros-model eclass and then the Python script, unless there is some other use hiding away somewhere.

Let me repeat the sentiment from #10. I'm really not into changing something like this for devices that are in MP (or very close to MP) and then having to deal with potential fallout across branches and validation on all devices. Please leave this alone on Coral.

> we have support for this in the master config, so perhaps we don't need to install files

I would say the support in master config is there but not complete, though. But even if this is complete we are still dealing with maintenance issue, IMHO.

Is this used anywhere other than coral? We could perhaps start by turning it off there?

Coral overlay is stable now, and is locked from refactoring while projects are moving through to MP.

Yes, will leave this until projects are through MP.

Note that Charles is planning to port to unibuilds v2 after Coral is done, which supports inheritance of this style, so it's unlikely there will ever be anything needed for this bug. 

When that happens, I expect that the parent files can be removed along with the code in cros-model.eclass, which is what this bug was filed for. We don't need to keep it open though.