Re: [Xen-devel] [PATCH 1/6] arm: make it possible to disable more kconfig options

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 22 May 2018, Julien Grall wrote:
> Hi,
> 
> On 05/21/2018 08:58 PM, Stefano Stabellini wrote:
> > On Thu, 19 Apr 2018, Julien Grall wrote:
> > > > +
> > > > +config HAS_MEM_ACCESS
> > > > +       bool
> > > > +       prompt "Memory Access and VM events"
> > > > +       default y
> > > 
> > > Most of the memaccess code is not protected by HAS_MEM_ACCESS.  So you are
> > > going to drop just a couple of hundreds line. Not sure if it is worth it
> > > in
> > > the actual state.
> > 
> > Yes, the LOC count it is not worth it today, but I would still like to
> > make it selectable because I don't want Xen to come to rely on having
> > HAS_MEM_ACCESS enabled all the time. !MEM_ACCESS is a good and valid
> > configuration. Also, we can go forward in making more stuff protected by
> > HAS_MEM_ACCESS soon.
> 
> The common code already doesn't rely on memaccess thanks to when Arm was not
> support it. While I agree that we don't want HAS_MEM_ACCESS enabled all the
> time, I question the usefulness of that possibility today. What you are going
> to remove is about ~150 lines of pumbling to the userspace. That's it.
> 
> All the meat (and complexity) of memaccess is still here (~500 lines). You can
> achieve the same situation with using XSM. So I don't see the real benefits of
> it here.
> 
> It would be better to first guard all memaccess code and then expose the
> config if we still think it is useful.

I am happy to hear that you also don't want HAS_MEM_ACCESS enabled all
the time. Then, it is just a question on when and how. Given that I am
doing kconfig changes now, I prefer to do them all at once, then move to
adding more #define (which I definitely intend to do next). It is very
easy to break these patches, they don't rebase easily, especially the
HAS_MEM_ACCESS rename. This is why I would prefer to make MEM_ACCES
optional as part of this series.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel