vio9p vs. GENERIC.local vs. XEN3_DOM[0U]

[Christoph Badura <bad%bsd.de@localhost>]

NB: redirecting followups to tech-kern.

Currently the vio9p driver is commented out in {i386,amd64}/conf/GENERIC:
#vio9p*	at virtio?			# Virtio 9P device

The obvious way to enable that is by adding a line to GENERIC.local:
vio9p*	at virtio?			

But doing so breaks the builds of the XEN3_DOM? kernels like so
    sys/arch/amd64/conf/GENERIC.local:1: `vio9p* at virtio?' is orphaned (nothing matching `virtio?' found)
because
$ grep cinclude {i386,amd64}/conf/*XEN3*
i386/conf/XEN3PAE_DOM0:cinclude "arch/i386/conf/GENERIC.local"
i386/conf/XEN3PAE_DOM0:cinclude "arch/i386/conf/XEN3_DOM0.local"
i386/conf/XEN3PAE_DOMU:cinclude "arch/i386/conf/GENERIC.local"
i386/conf/XEN3PAE_DOMU:cinclude "arch/i386/conf/XEN3_DOMU.local"
amd64/conf/XEN3_DOM0:cinclude   "arch/amd64/conf/GENERIC.local"
amd64/conf/XEN3_DOMU:cinclude   "arch/amd64/conf/GENERIC.local"
amd64/conf/XEN3_DOMU:cinclude   "arch/amd64/conf/XEN3_DOMU.local"

This is extremely annoying, as that breaks "build.sh release" because that
builds the XEN3 kernels.  And it prevents us from enabling vio9p on x86
kernels by default.

The obvious and simplest fix is to make the XEN3 kernels stop including
GENERIC.local.  (And make amd64 XEN3_DOM0 cinclude XEN3_DOM0.local as on
i386.)

The less trivial fix is to conditionally attach vio9p in GENERIC.local.
config(8) has "ifdef"/"ifndef" directives for that.  But they key on
config attributes and I couldn't find an attribute that is only present in
XEN kernels.

Now, Someone(TM) could probably go into config(8) and add a way to
conditionalize on flags.  But that is way more work and, IMHO, tackling
the problem at the wrong level of abstraction.

It seems to me that the best way to remedy the situation is to make the
XEN3 kernels not include GENERIC.local.

If people really want to include GENERIC.local they can do so in their
XEN3_DOM?.local files or create a XEN3.local (or XEN3.common.local or
whatever) that is included from them.

--chris