tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Christoph Badura <bad%bsd.de@localhost> writes:

> 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.)

I don't think that's reasonable at all.  GENERIC.local is for things you
want in your kernels, and if it's something else, then it certainly
belongs in XEN kernels.

You have merely found something is problematic because it assumes there
is virtio.

> 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.

The right level of abstraction is to do something that says

  if there is a virtio bus, add viop* at virtio*

and this is true of pretty much anything that attaches to a bus that may
or may not present.

I wonder if there are good reasons to avoid "just skip lines that refer
to a bus that don't exist".

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

That will break a lot of other things, and many will find it very
surprising.

> 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.

If you really want this, you can just add it to GENERIC.  That seems
better than asking the rest of the world to change.  But seriously, I
don't see why making XEN not include GENERIC.local is better than
people that want bus-specific things putting it someplace else.

You could also add

GENERIC.local.virtio

and include it from all kernels that have virtio.



Home | Main Index | Thread Index | Old Index