On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich <jbeul...@suse.com> wrote:

> >>> On 20.09.16 at 14:35, <de...@asterius.io> wrote:
> > On Wed, Sep 14, 2016 at 6:47 AM, Jan Beulich <jbeul...@suse.com> wrote:
> >
> >> >>> On 13.09.16 at 21:40, <de...@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 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
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.


> Jan
Xen-devel mailing list

Reply via email to