All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oskar Senft <osk@google.com>
To: Andrew Jeffery <andrew@aj.id.au>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	 Patrick Williams <patrick@stwcx.xyz>
Cc: Ali El-Haj-Mahmoud <aaelhaj@google.com>
Subject: Re: Making obmc-console_git.bb more generic (again)?
Date: Wed, 24 Nov 2021 15:35:27 -0500	[thread overview]
Message-ID: <CABoTLcS1=8fp09RZxxpfha3L7REEgaBht3ivtCx5Ex-y5aDx7g@mail.gmail.com> (raw)
In-Reply-To: <48d0cc9e-6ab6-4d94-a8aa-1be8b8c1f155@www.fastmail.com>

Hi everyone

I just sent https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/49082
for review.

It took me a while to test (mainly because Yocto is weird). From what
I can tell, this should be fully "backwards" compatible with existing
meta machine layers that do or do not use the OBMC_CONSOLE_HOST_TTY
variable.

Oskar.

On Mon, Nov 22, 2021 at 6:20 PM Andrew Jeffery <andrew@aj.id.au> wrote:
>
>
>
> On Tue, 23 Nov 2021, at 03:25, Patrick Williams wrote:
> > 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.
>
> Yeah I'm not sure what happened here, whether that was something I did
> or if someone's made changes to the recipe since. When I added support
> for exposing multiple devices from the one BMC there were some
> complications around not breaking everyone vs having to modify every
> in-tree consumer. I didn't have the bandwidth or ability to test fixing
> all the platforms at the time so I put some work-arounds in the install
> phase of the obmc-console recipe. Maybe that broke things?
>
> Anyway, please also CC me on cleanups.
>
> Cheers,
>
> Andrew

      reply	other threads:[~2021-11-24 20:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-17 22:01 Making obmc-console_git.bb more generic (again)? Oskar Senft
2021-11-22 16:55 ` Patrick Williams
2021-11-22 23:20   ` Andrew Jeffery
2021-11-24 20:35     ` Oskar Senft [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABoTLcS1=8fp09RZxxpfha3L7REEgaBht3ivtCx5Ex-y5aDx7g@mail.gmail.com' \
    --to=osk@google.com \
    --cc=aaelhaj@google.com \
    --cc=andrew@aj.id.au \
    --cc=openbmc@lists.ozlabs.org \
    --cc=patrick@stwcx.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.