From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CBDCB21A04823 for ; Mon, 1 May 2017 16:07:50 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 36EBF17C50A; Mon, 1 May 2017 23:07:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 36EBF17C50A Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 36EBF17C50A Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-22.phx2.redhat.com [10.3.117.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2F5177F383; Mon, 1 May 2017 23:07:48 +0000 (UTC) To: Jordan Justen , edk2-devel-01 References: <20170429201500.18496-1-lersek@redhat.com> <20170429201500.18496-3-lersek@redhat.com> <149351328512.20670.1563878734495138189@jljusten-skl> <030f8312-35ce-5c86-205c-2ee6c0b5ab8b@redhat.com> <149358697668.23065.6363402854761002239@jljusten-skl> <149365940885.25909.1007719045522991203@jljusten-skl> <88d156c9-c18e-c4e8-b9a3-641a1b6b4102@redhat.com> <149366640991.26266.1222435765632598609@jljusten-skl> Cc: Gary Ching-Pang Lin From: Laszlo Ersek Message-ID: <62f44903-c06a-fb0f-0761-17cf9107620e@redhat.com> Date: Tue, 2 May 2017 01:07:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149366640991.26266.1222435765632598609@jljusten-skl> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 01 May 2017 23:07:50 +0000 (UTC) Subject: Re: [PATCH 2/3] OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 23:07:51 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: ). *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