Re: [PATCH 2/3] OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK

[Jordan Justen <jordan.l.justen@intel.com>]

On 2017-05-01 11:40:58, Laszlo Ersek wrote:
> On 05/01/17 19:23, Jordan Justen wrote:
> > On 2017-05-01 03:51:42, Laszlo Ersek wrote:
> >> On 04/30/17 23:16, Jordan Justen wrote:
> >>> On 2017-04-30 07:42:36, Laszlo Ersek wrote:
> >>>
> >>>> $ build \
> >>>>   -b DEBUG \
> >>>>   -a IA32 -a X64 \
> >>>>   -p OvmfPkg/OvmfPkgIa32X64.dsc \
> >>>>   -t GCC48 \
> >>>>   -D SMM_REQUIRE \
> >>>>   -D SECURE_BOOT_ENABLE \
> >>>>   -D HTTP_BOOT_ENABLE \
> >>>>   -D NETWORK_IP6_ENABLE \
> >>>>   -D TLS_ENABLE
> >>>
> >>> Do you enable the last 3 in your production builds? I didn't think it
> >>> was the case, but it would change things...
> >>
> >> That's a very good question, and I expected it.
> >>
> >> Any sane person being responsible for supporting a package will strive
> >> very hard to minimize the features enabled in the package, in order to
> >> minimize the problem surface / support burden. I tend to consider myself
> >> a sane person, so no, HTTP_BOOT_ENABLE, NETWORK_IP6_ENABLE, and
> >> TLS_ENABLE are not turned on.
> >>
> >> (TLS_ENABLE carries even more weight, because it increases the security
> >> attack surface, so turning *that* off is very desirable.)
> >>
> >> *But*, I certainly want to keep the *ability* to turn these features on
> >> (and maybe later features, in 2-3 years' time) if a customer or a
> >> partner requests it.
> > 
> > It sounds like you don't expect to 'support' this. At least not to the
> > same level as the rest of the firmware.
> 
> I hope never to have to support these, but at some point into the future
> of RHEL7, I might have no choice.
> 
> > I think it is fine to say, if you want to enable these, you may have
> > to disable debug on some other features,
> 
> As I explained earlier, universal DEBUG coverage is a requirement for
> supportability.
>

The DEBUG for everything is *your* requirement. I'm fine to work with
that on the standard set of features.

But, you've already admitted that these are not features you currently
support, or plan to anytime soon. So, don't hold them up as must have
features when you are not even using them.

At this I'd just like figure out what to do about the 4MB layout, so
can we stop getting worked up over this side show? Obviously you are
going to start using the new 4MB layout, and everything will fit
easily with debug there.

> > In other words, at this point I don't think the size of these should
> > be added into the equation for how 'full' the 2MB image is.
> 
> I think at this point it is clear that these patches are not appropriate
> for upstream OvmfPkg.

I don't know how you came to this conclusion.

I think at this point you've convinced (heh) me that we should figure
out a 4MB layout, and obviously it'd be better to have a single 4MB
layout. (See other email.)

-Jordan