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

[Laszlo Ersek <lersek@redhat.com>]

On 05/01/17 21:20, Jordan Justen wrote:
> 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.

Sure.

> I'm fine to work with
> that on the standard set of features.

Above when you wrote

  I think it is fine to say, if you want to enable these, you may have
  to disable debug on some other features

did you not mean that for *my* use case (emphasis yours)?

> 
> But, you've already admitted that these are not features you currently
> support, or plan to anytime soon.

I'm wary of future "offers" in the area that I possibly "can't refuse".
And when talking about area reservations, that is the same thing as
"wanting to support it real hard right now".

(Also, I didn't "admit" it. I confirmed it. I didn't mis-represent or
hide my use case, and you didn't catch me in any such
mis-representation, so there was nothing for me to admit.)

> So, don't hold them up as must have
> features when you are not even using them.

"In two years, I'm possibly buying a really large fridge. I don't want
that fridge, but my kids can eat a lot, and in two years, they are going
to eat even more (growing up!). So, if it's not a big burden, let's make
the kitchen door big enough now while we are remodeling anyway for the
fridge to fit through."

"Don't hold up that fridge as a must have when you are not even using it."

> 
> 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?

Thanks for calling it a side show, real friendly.

Also, I haven't noticed myself getting worked up, but now we're on a
good path to that.

> Obviously you are
> going to start using the new 4MB layout, and everything will fit
> easily with debug there.

Yes. And the one thing you've failed to express clearly until now is why
exactly you dislike the exact size increases in the patch.

> 
>>> 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.

After several rounds of discussion, you still prefer ~128KB of varstore,
which is barely above the latest minimum requirements. Being frugal is
good in general (see e.g. one of my own arguments here:
<http://mid.mail-archive.com/56F40D1A.50801@redhat.com>). *But*, in this
case, every time we're going to grow the varstore, compatibility will
break. So it makes sense to go beyond the exact current requirement and
buy some time until the next breakage. Decrease the frequency of
breakage if you will. The desired amount of time bought differs, of
course. I can't predict the future but would like to aim at a large
margin, with ~7 years. You can't predict the future but would like to
aim at a zero margin. I've come to equate your preference with what's
appropriate for upstream. Therefore the patches I posted aren't. QED.

> 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.)

The only email (that I can see) in this thread that I haven't reacted to is:

http://mid.mail-archive.com/149365894632.25909.11739243410891079091@jljusten-skl

where you wrote "I'd rather go with 128k, and I'd also rather stay with
2MB".

Laszlo