----- Original Message ----- > On 01/10/2012 05:44 AM, Stefano Stabellini wrote: > > On Mon, 9 Jan 2012, Andrew Jones wrote: > >> I guess if we did the s/XEN_DOM0/LOCAL_APIC && IO_APIC && ACPI/ in > >> arch/x86/pci/xen.c it would be pretty easy to review for > >> equivalence. > >> Then keep CONFIG_PRIVILIGED, but drop XEN_DOM0 from everywhere > >> else and > >> compile in the 3 files. I don't think it makes much sense to do it > >> though. XEN_DOM0 keeps things tidier now and might be useful > >> later. > > we can keep things clean with the following: > > > > #ifdef CONFIG_LOCAL_APIC && CONFIG_IO_APIC && CONFIG_ACPI && > > CONFIG_PCI_XEN > > > > #define XEN_DOM0 > > > > #endif > > > > in include/xen/xen.h. > > > > So in the source files we can still '#ifdef XEN_DOM0', but at the > > same > > time we can get rid of the build symbol: everybody wins. > > No, really, I think this is silly. This kind of dependency > information > should be encoded in the Kconfig system, and not reimplemented in an > ad-hoc way. > > If there were a clean way to do what Andrew wants then I'd support > it, > but this thread has descended into a spiral of madness, which makes > me > think its a lost cause. > > If the root complaint is that "customers think that anything set in > .config is a supported feature", then the solutions are to support > all > the features in .config, re-educate the customers that they're wrong, > or > maintain a local patch to do this stuff. If only re-educating people was free, like preempting questions is. Local patches are of course always an option, and perhaps in this case it's the best one. However, I think we already made a case for better xen configurability for the driver domains, so I'm not 100% convinced my initial patch (making dom0 configurable) isn't worthy of upstream. Also, I didn't see any comments on my v2[*] of that patch, which I believe satisfies the menu complexity issue and brings in more configurability. That said, I'm about to reply to that patch myself, since there's an issue with it. Drew [*] http://article.gmane.org/gmane.linux.kernel.virtualization/14635 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
