public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"rebecca@bsdio.com" <rebecca@bsdio.com>,
	Laszlo Ersek <lersek@redhat.com>,
	"Justen, Jordan L" <jordan.l.justen@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2-devel] Adding Bhyve support into upstream EDK2
Date: Sat, 7 Mar 2020 01:29:44 +0000	[thread overview]
Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F972D18@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <fefaf362-78d2-8914-26a6-ce1a72c02812@bsdio.com>

I can share some of my experience, for your information only.

0) If the patch is generic, not specific to Bhyve, but benefit to current EDKII pkg, you can submit them directly. No need to wait for Bhyve.

1) If the patch is very simple, you can merge into current PKG with current DSC.
If there is something special to the Bhyve that can be detected at runtime, then detect at runtime.
If there is something special to the Byhve that need to be determine at build time, then you can introduce a PCD (such as PcdBhyveXXX) and configurate at build time.

2) If the patch is big, you can introduce a standalone driver and put to current PKG and introduce a new DSC file (such as OvmfBhyve.dsc). You can control and build Byhve with the new DSC file.

3) If the patch is extremely big and has architecture difference, you can introduce a new pkg (BhyvePkg) and put all new drivers there. You can still refer to some drivers in OvmfPkg, which introduce a dependency (BhyvePkg => OvmfPkg). The OvmfPkg change may impact BhyvePkg build or running.

X) Last but not least important, if the Bhyve has a different *security requirement* or *threat model* with current Pkg, then you had better introduce a new pkg or update the current Pkg with same threat model. Before that, you had better not use any driver in other package and keep them separate. It is easy for future audit purpose.

Above is the generic rule. I think OvmfPkg maintainer can provide more comment on that.

Can you post the patch? :-)

Thank you
Yao Jiewen

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Rebecca
> Cran
> Sent: Saturday, March 7, 2020 12:10 AM
> To: devel@edk2.groups.io; Laszlo Ersek <lersek@redhat.com>; Justen, Jordan L
> <jordan.l.justen@intel.com>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: [edk2-devel] Adding Bhyve support into upstream EDK2
> 
> I'm currently working on updating EDK2 support for Bhyve
> (https://bhyve.org/) from the edk2-stable201903 tag to
> edk2-stable202002. It's currently kept in a separate repo
> (https://github.com/freebsd/uefi-edk2), but I'd like to discuss pushing
> support upstream into the main edk2 repo (I guess into edk2-staging as a
> first step?).
> 
> 
> Would that be something people would be open to considering, or should
> it remain separate? Should it be a new top-level package (e.g. BhyvePkg)
> or could it be just a configuration option when building OVMF? It's
> currently maintained as a set of patches against OvmfPkg, which seems to
> work quite well.
> 
> 
> --
> Rebecca Cran
> 
> 
> 
> 


  parent reply	other threads:[~2020-03-07  1:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-06 16:09 Adding Bhyve support into upstream EDK2 Rebecca Cran
2020-03-06 19:54 ` Laszlo Ersek
2020-03-06 20:04   ` [edk2-devel] " Laszlo Ersek
2020-03-07  1:29 ` Yao, Jiewen [this message]
2020-03-24  1:34   ` Rebecca Cran
2020-03-25  0:04     ` Laszlo Ersek
2020-03-25 18:18       ` [EXTERNAL] " Bret Barkelew
2020-03-27 12:56         ` Laszlo Ersek
2020-03-25 18:50       ` Rebecca Cran
     [not found] ` <15F9E16A0219E7B7.19404@groups.io>
2020-03-07  1:43   ` Yao, Jiewen
2020-03-07  7:39     ` Laszlo Ersek
2020-03-07  7:52       ` Ard Biesheuvel
2020-03-08  2:40         ` Rebecca Cran
2020-03-09  6:08         ` Sean
2020-03-09 22:54           ` Laszlo Ersek
2020-03-09 23:17             ` Laszlo Ersek
2020-03-10  1:50               ` Sean
2020-03-10  9:05                 ` Laszlo Ersek
2020-03-10 17:25                   ` Sean
2020-03-10 17:54                     ` Ard Biesheuvel
2020-03-10 19:10                       ` Sean
2020-03-10 19:23                         ` Michael D Kinney
2020-03-10 19:44                           ` Sean
2020-03-10 20:04                             ` Rebecca Cran
2020-03-11  0:05                             ` Laszlo Ersek
2020-03-11  0:30                               ` Sean
2020-03-11  3:21                             ` Liming Gao
2020-03-10 23:34                     ` Laszlo Ersek
2020-03-11  0:43           ` Leif Lindholm
2020-03-07  7:53       ` Laszlo Ersek

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-list 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=74D8A39837DF1E4DA445A8C0B3885C503F972D18@shsmsx102.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /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