Re: CVS commit: src/sys/arch/amd64/conf

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 12 Oct 2014 00:17:22 +0900
    From:        Masao Uebayashi <uebayasi%gmail.com@localhost>
    Message-ID:  <CADbF7ecEM8n2VhQ_9AtS2YsjZX-zL-4cg65jTd7vuu0niGtz-Q%mail.gmail.com@localhost>

For what it is worth, this change (below) just "bit" me - I did my first new
builds for a couple of weeks, and my own Dom0 config failed to build
(because even though the standard XEN3_DOM0 got the include ... added to it,
my private config file, that is tailored to my sustem (which does have
atheros wireless) did not have that, just the "ath* at ..." stuff.

The link failed in a way that was (to me) bizarre...

  | On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
  | > On Sat, Oct 11, 2014 at 09:50:03AM +0000, Masao Uebayashi wrote:

  | >> Don't include std.ath_hal for XEN3_DOMU.
  | >
  | > Why ?

  | Including "std.ath_hal" means that you pull in ath device code in your
  | kernel.

No it doesn't.  All it is is a bunch of option definitions, by themselves,
those do (or should do) nothing.   What's more, I verified that my DomU
kernels from before this change had no ath related code in them at all (I'm
not interested in the possibility of pci passthrough, or at least, not
right now) and my Dom0 kernel did (as it was intended to).

As I see it, all the ath code is conditioned by at least requiring "ath"
which is obtained by having "ath* at" in the config file somewhjere (which
normally DOM0 does, and DOMU does not).   That includes ath code in DOM0
and excludes it from DOMU, and all this has seemed to work essentially 
forever.   What has changed, or is changing that makes specifying a
useless option do anything different?   The options to include the various
different ath drivers - or whatever they do - might truly be better explicitly
listed in the config files, so only the appropriate ones will be included,
but just including all or nothing via std.ath_hal being there or not
doesn't seem like it is the correct level of granualarity.  That is, if the
way the drivers are written (currently) even allows selecting one, or two,
but not all (no idea, I have never tried.)

Now, clearly fixing this for my kernel config just meant adding the include
line (once I found this particular change) - but I don't really think that's
the way kernel config files should be written.

kre