On Sun, Oct 12, 2014 at 03:35:48AM +0900, Masao Uebayashi wrote: > On Sun, Oct 12, 2014 at 3:06 AM, Manuel Bouyer <bou...@antioche.eu.org> wrote: > > On Sun, Oct 12, 2014 at 12:17:22AM +0900, Masao Uebayashi wrote: > >> On Sun, Oct 12, 2014 at 12:05 AM, Manuel Bouyer <bou...@antioche.eu.org> > >> wrote: > >> > On Sat, Oct 11, 2014 at 09:50:03AM +0000, Masao Uebayashi wrote: > >> >> Module Name: src > >> >> Committed By: uebayasi > >> >> Date: Sat Oct 11 09:50:03 UTC 2014 > >> >> > >> >> Modified Files: > >> >> src/sys/arch/amd64/conf: XEN3_DOM0 std.xen > >> >> > >> >> Log Message: > >> >> Don't include std.ath_hal for XEN3_DOMU. > >> > > >> > Why ? > >> > We still support PCI pass-through, so we could have a ath in a domU > >> > >> In that case you have to enable xpci/pci at first. > >> > >> Including "std.ath_hal" means that you pull in ath device code in your > >> kernel. But you don't have no parent buses. This might be OK for > >> ath(4), but in general, it means that config(1) doesn't resolve > >> dependency, and your kernel may be bloated by unnecessary code. > > > > why isn't this compiled in only when ath(4) is inclued in config file ? > > isn't that what attributes are for ? > > I don't understand. If you say "config file", is it files.* > (definition) or std.* (selection)?
OK, I see. But I still think config should be able to include theses only if ath or athn is there; wouldn't adding " & ath" at appropriate places in files.ath_hal be enough for this to happen ? -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --