From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (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 032E321A04823 for ; Mon, 1 May 2017 12:20:11 -0700 (PDT) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP; 01 May 2017 12:20:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,401,1488873600"; d="scan'208";a="255617439" Received: from pguermon-mobl3.ger.corp.intel.com (HELO localhost) ([10.255.77.18]) by fmsmga004.fm.intel.com with ESMTP; 01 May 2017 12:20:10 -0700 MIME-Version: 1.0 To: Laszlo Ersek , edk2-devel-01 Message-ID: <149366640991.26266.1222435765632598609@jljusten-skl> From: Jordan Justen In-Reply-To: <88d156c9-c18e-c4e8-b9a3-641a1b6b4102@redhat.com> Cc: Gary Ching-Pang Lin 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> User-Agent: alot/0.5.1 Date: Mon, 01 May 2017 12:20:10 -0700 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 19:20:11 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 myse= lf > >> 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