On Wed, Nov 17, 2021 at 05:01:25PM -0500, Oskar Senft wrote:
> Hi everyone
> 
> I noticed that as of
> https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/30369 (aka
> https://github.com/openbmc/openbmc/commit/abf95efe7c3a34cc2e5d7424abb59710fb4a1d4d),
> obmc-console_git.bb assumes that we always want to use ttyVUART0.

There was a push to move service files outside of the openbmc/openbmc repository
and into the underlying repos.  Brad could comment on why as he was
asking for it.

> We used to have support for OBMC_CONSOLE_HOST_TTY and then create the
> symlink /etc/obmc-console/server.${OBMC_CONSOLE_HOST_TTY}.conf as
> needed.
> 
> From what I can tell, OBMC_CONSOLE_HOST_TTY is still used in quite a
> few machine layers. Some of them (e.g. meta-amd and meta-facebook)
> even went so far to replicate the previous behavior by deleting
> /etc/obmc-console/server.VUART0.conf and then re-creating the correct
> one.

Speaking for the Facebook machines, we have some machines which use a different
vTTY and we have other machines which manage multiple hosts and thus have
multiple vTTYs.  We probably should have contributed code to pass the desired
vTTY(s) as a meson-option.

> Is this actually the expected behavior? Or was that just an oversight
> in the commit?

I think it was the "put the default/typical config into the repo and let
everyone customize it otherwise if they need" approach.

> I'd be happy to send a review request to make this generic again if
> people agree. A bunch of follow-up commits could then remove the
> duplicate code in individual machine layer overrides.

I'd be thankful for this.  Please feel free to add me as a reviewer.

-- 
Patrick Williams