From mboxrd@z Thu Jan 1 00:00:00 1970 From: Derek Straka Subject: Re: [PATCH] x86: add a user configurable Kconfig option for the VGA Date: Tue, 20 Sep 2016 10:26:01 -0400 Message-ID: References: <1473795628-14268-1-git-send-email-derek@asterius.io> <57D946F0020000780010EBDA@prv-mh.provo.novell.com> <57E151FA0200007800110A07@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4241066473486919122==" Return-path: In-Reply-To: <57E151FA0200007800110A07@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich Cc: andrew.cooper3@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============4241066473486919122== Content-Type: multipart/alternative; boundary=001a114057484d5cb7053cf1354b --001a114057484d5cb7053cf1354b Content-Type: text/plain; charset=UTF-8 On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich wrote: > >>> On 20.09.16 at 14:35, wrote: > > On Wed, Sep 14, 2016 at 6:47 AM, Jan Beulich wrote: > > > >> >>> On 13.09.16 at 21:40, wrote: > >> > Allows for the conditional inclusion of VGA driver on the x86 platform > >> > rather than having it always enabled. > >> > >> So I guess with all three of these patches an overview mail is missing. > >> What are you trying to accomplish? Solely reducing the binary size of > >> Xen doesn't seem like a very important goal to me, and eliminating > >> these drivers from the build doesn't appear to help make Xen more > >> stable of secure. > >> > > I agree with your assessment on the stability and security standpoint. > Our > > customer has asked us to remove > > unused drivers based on functionality of a set of boards. Each of the > > boards has a subset of the available hardware functionality > > brought out to accessible headers. > > Well, does that mean that's just to reduce the size of the hypervisor? > If so, I'm honestly not sure we want to set a precedent here, since > if we do, people could come and suggest to make all sorts of code > build conditionally, and I don't think our plans with Kconfig so far were > going in that direction (but others may disagree with me here). > > For the most part: yes. At the end of the day, my customer wants to reduce the size of hypervisor. I disagree a bit that these specific changes would set a poor precedent of for configuration. The reason I proposed it in the first place was the mechanisms for conditional compilation were already implicitly available via HAS_*. I thought adding the ability for the user to explicitly define the configuration option would be a permissible extension of the capability already present. That said, I do see your point about limiting the scope of conditional code to avoid an eventual mess. Thanks. -Derek > Jan > --001a114057484d5cb7053cf1354b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich <JBeulich@suse.com>= ; wrote:
>>> On 20.= 09.16 at 14:35, <= derek@asterius.io> wrote:
> On Wed, Sep 14, 2016 at 6:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
>
>> >>> On 13.09.16 at 21:40, <derek@asterius.io> wrote:
>> > Allows for the conditional inclusion of VGA driver on the x86= platform
>> > rather than having it always enabled.
>>
>> So I guess with all three of these patches an overview mail is mis= sing.
>> What are you trying to accomplish? Solely reducing the binary size= of
>> Xen doesn't seem like a very important goal to me, and elimina= ting
>> these drivers from the build doesn't appear to help make Xen m= ore
>> stable of secure.
>>
> I agree with your assessment on the stability and security standpoint.= =C2=A0 Our
> customer has asked us to remove
> unused drivers based on functionality of a set of boards.=C2=A0 Each o= f the
> boards has a subset of the available hardware functionality
> brought out to accessible headers.

Well, does that mean that's just to reduce the size of the hyper= visor?
If so, I'm honestly not sure we want to set a precedent here, since
if we do, people could come and suggest to make all sorts of code
build conditionally, and I don't think our plans with Kconfig so far we= re
going in that direction (but others may disagree with me here).

For the m= ost part: yes.=C2=A0 At the end of the day, my customer wants to reduce the= size of hypervisor.=C2=A0 I disagree a bit that these specific changes=C2= =A0
would set a poor precedent of for configuration.=C2=A0 The re= ason I proposed it in the first place was the mechanisms for conditional co= mpilation=C2=A0
were already implicitly available via HAS_*.=C2= =A0 I thought adding the ability for the user to explicitly define the conf= iguration option
would be a permissible extension of the capabili= ty already present.=C2=A0 That said, I do see your point about limiting the= scope of conditional=C2=A0
code to avoid an eventual mess.=C2=A0= Thanks.

-Derek=C2=A0
Jan

--001a114057484d5cb7053cf1354b-- --===============4241066473486919122== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============4241066473486919122==--