All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stewart Smith <stewart@linux.vnet.ibm.com>
To: Adriana Kobylak <anoo@linux.vnet.ibm.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: OpenBMC Image Management
Date: Wed, 12 Jul 2017 07:47:18 +1000	[thread overview]
Message-ID: <87a84abq8p.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <ED39C0D3-EE2E-4D03-9B70-D6F0AD0F3AC7@linux.vnet.ibm.com>

Adriana Kobylak <anoo@linux.vnet.ibm.com> writes:
>> On Jun 21, 2017, at 12:42 AM, Stewart Smith <stewart@linux.vnet.ibm.com> wrote:
>> 
>> Adriana Kobylak <anoo@linux.vnet.ibm.com <mailto:anoo@linux.vnet.ibm.com>> writes:
>>>> On Jun 19, 2017, at 12:44 AM, Stewart Smith <stewart@linux.vnet.ibm.com> wrote:
>>>> 
>>>> Adriana Kobylak <anoo@linux.vnet.ibm.com> writes:
>>>>>> Why is there mboxbridge separate from phosphor-mboxd?
>>>>> 
>>>>> Because the mboxbridge is being used by other companies as a reference
>>>>> to be able to implement the mailbox daemon in their own BMC firmware
>>>>> stack for other openpower systems, we didn’t want to “pollute” the
>>>>> repository with openbmc-specific and c++ implementation that could
>>>>> confuse them.
>>>> 
>>>> Why are there OpenBMC specific things in mboxd?
>>>> 
>>>> Why can't the reference implementation be used? What's deficient in it?
>>> 
>>> For OpenBMC, we’re having the PNOR chip with a filesystem, so mboxd
>>> would read/write files instead of looking for the data at an offset in
>>> the chip. Nothing deficient with it, just a different implementation
>>> that needs to be handled.
>> 
>> Why not have an MBOX protocol that supports partitions/files natively
>> then? Why not develop this upstream? Surely this is something others
>> could be interested in.
>> 
> It’d be available in the openbmc/phosphor-mboxd repo for anybody that
> wants to use it. Or what do you mean by develop it upstream?

I mean in https://github.com/openbmc/mboxbridge - the reference
implementation.

>> It seems really backwards having a bunch of things convert to/from FFS
>> for no reason.
>
> We’re not converting back and forth, if the pnor is blank, we’ll
> attach ubi to it, and if the pnor is formatted as ffs it’ll be
> reformatted once to ubi.

I mean that I don't see any patches changing how we build things in
op-build, so there has to be some unpacking of the content going on
there.

-- 
Stewart Smith
OPAL Architect, IBM.

  reply	other threads:[~2017-07-11 21:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-25 22:15 OpenBMC Image Management Adriana Kobylak
2017-01-25 23:50 ` Chris Austen
2017-01-27  3:07   ` Patrick Williams
2017-01-30  5:47     ` Stewart Smith
2017-01-31 18:16       ` Patrick Williams
2017-01-31 18:33         ` Rick Altherr
2017-06-13 18:10           ` Adriana Kobylak
2017-06-13 21:45             ` Stewart Smith
2017-06-18 19:48               ` Adriana Kobylak
2017-06-19  5:44                 ` Stewart Smith
2017-06-20 14:38                   ` Adriana Kobylak
2017-06-20 15:03                     ` Chris Austen
2017-07-11  0:53                       ` Adriana Kobylak
2017-06-21  5:42                     ` Stewart Smith
2017-07-11  1:47                       ` Adriana Kobylak
2017-07-11 21:47                         ` Stewart Smith [this message]
2017-08-02 18:04                           ` Adriana Kobylak
2017-08-02 17:23             ` OpenBMC Image Management - Witherspoon Adriana Kobylak
2017-08-03  0:19               ` Stewart Smith
2017-08-03  1:53               ` Andrew Geissler
2017-09-21 20:40               ` Adriana Kobylak
2017-01-26 10:43 ` OpenBMC Image Management Anton D. Kachalov
2017-01-26 15:33   ` Adriana Kobylak
2017-01-26 21:38     ` Rick Altherr
2017-01-30  5:50     ` Stewart Smith
2017-01-30  5:51   ` Stewart Smith
2017-01-30  5:54 ` Stewart Smith
2017-01-30  5:55 ` Stewart Smith
2017-06-16 22:18 ` Maxim Sloyko
2017-06-20 14:34   ` Adriana Kobylak
2017-08-02 17:15   ` Adriana Kobylak
2017-08-03  0:14     ` Benjamin Herrenschmidt
2017-08-03  5:55       ` Patrick Williams
     [not found]       ` <20170803055546.A99FA112040@b01ledav004.gho.pok.ibm.com>
2017-08-03  5:59         ` Benjamin Herrenschmidt
2017-08-07 22:02           ` Milton Miller II

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=87a84abq8p.fsf@linux.vnet.ibm.com \
    --to=stewart@linux.vnet.ibm.com \
    --cc=anoo@linux.vnet.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    /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.