kern/51908: cinclude of xen kernel configs

[amonk%backwatcher.com@localhost]

	Note: There was a bad value `' for the field `Confidential'.
	It was set to the default value of `yes'.

>Number:         51908
>Category:       kern
>Synopsis:       xen kernel configs cinclude GENERIC.local
>Confidential:   yes
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 23 04:05:00 +0000 2017
>Originator:     Kyle Amon
>Release:        NetBSD 7.0.2_PATCH
>Organization:
BackWatcher, Inc.
	
>Environment:
	
	
System: NetBSD nbsd.backwatcher.com 7.0.2_PATCH NetBSD 7.0.2_PATCH (XEN3_DOM0) amd64
Architecture: x86_64
Machine: amd64
>Description:
The XEN3_DOM0 and XEN3_DOMU kernel config files have cinclude
lines that default to including GENERIC.local.  This causes conflicts.  For
example, if one wants Segvguard in a XEN kernel, one would have to add an
'options FILEASSOC' to GENERIC.local (since its a dependency of Segvguard),
and all is well with the XEN_DOM? build, but when one wants to then build
GENERIC (to keep as an emergency/maintenance kernel as well, for example),
the GENERIC build fails because FILEASSOC is alreadu in GENERIC.  So, one
must manually comment and uncomment things in GENERIC.local depending upon
wheather one wants to build a GENERIC or a XEN_DOM? kernel, or modify the
XEN_DOM? kernel config cinclude line (and manage the difference therafter),
or keep seperate XEN_DOM?_FOO kernels with the modified (fixed) cinclude,
all of which are cumbersome and wholely unencessary.
	
>How-To-Repeat:
Try to build both GENERIC and XEN3_DOM0 with Segvguard.
>Fix:
Change the XEN_DOM? kernel config cinclude lines (for both amd64 and
i386) to include .local files consistent with their own names, like so,
respectively...

cinclude "arch/amd64/conf/XEN3_DOM0.local"
cinclude "arch/amd64/conf/XEN3_DOMU.local"

and...

cinclude "arch/i386/conf/XEN3_DOM0.local"
cinclude "arch/i386/conf/XEN3_DOMU.local"

...so that users can create and use individual, kernel name consistent,
non-conflicting include files, instead of having to resort to some ungainly
method of fighting conflicts which shouldn't exist in the first place.

>Unformatted: