openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Kerr <jk@ozlabs.org>
To: Vernon Mauery <vernon.mauery@linux.intel.com>
Cc: Matt Spinler <mspinler@linux.vnet.ibm.com>, openbmc@lists.ozlabs.org
Subject: Re: Virtual Media
Date: Wed, 1 Aug 2018 08:56:56 +0800	[thread overview]
Message-ID: <e1b784dc-3434-cfda-a07b-3a065458fef0@ozlabs.org> (raw)
In-Reply-To: <20180731180257.GJ105329@mauery>

Hi Vernon,

> In past BMC implementations, we offered up to four virtual devices to be 
> mounted remotely. I can't remember if this included the one used for 
> firmware updates or not. But we will probably need more than one.

That would definitely be possible with this design, we'd just need to
parameterise the nbd device and USB endpoint.

However, I've personally never encountered a need for more than one
virtual media device. As you say, most of this will be for host OS
installs.

But if we do have a compelling case to implement multiple devices, that
shouldn't be a hassle.

> That sounds pretty good from a high level. Nice job using off-the-self 
> parts.

Thanks! Was nice to find that we didn't need to implement custom
protocols & kernel interfaces for this.

> RO files should really be the biggest use case for this -- host OS 
> installs and such. I really don't know how much people will complain if 
> we take their RW files away.

Yes, I'd agree there. As above, I'm not sure how much this would be
used. The one use-case I can imagine is a small writeable filesystem for
saving debug logs (in our case, from petitboot). However, we also have
actual host network available at that point...

It *could* be possible to do RW media in javascript by storing CoW data
of modified blocks client-side (eg, in an IndexedDB). The UX isn't great
for this though, as the user would need to explicitly "download" and
save the modified file after use (and I guarantee that folks will forget
to do that and lose data).

> We are also not requiring them to install Java,

Hooray! :)

Cheers,


Jeremy

  reply	other threads:[~2018-08-01  0:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-18 21:55 Virtual Media Matt Spinler
2018-07-26 16:29 ` Matt Spinler
2018-07-27  9:06 ` Jeremy Kerr
2018-07-31 18:02   ` Vernon Mauery
2018-08-01  0:56     ` Jeremy Kerr [this message]
2018-08-01  4:12       ` Stewart Smith
2018-08-01  4:18         ` Jeremy Kerr
2018-08-01  5:07           ` Stewart Smith
2018-12-10 17:43   ` Adriana Kobylak
2018-12-10 19:13     ` Ed Tanous
2019-10-09 21:11 Rapkiewicz, Pawel
2019-10-10 19:30 ` Adriana Kobylak
2019-10-10 22:21   ` Ed Tanous

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=e1b784dc-3434-cfda-a07b-3a065458fef0@ozlabs.org \
    --to=jk@ozlabs.org \
    --cc=mspinler@linux.vnet.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=vernon.mauery@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).