Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge',no'le'in kernel config)

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

The following reply was made to PR kern/48579; it has been noted by GNATS.

From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: kern/48579: #34490 (kernel compile fails in 
`le_isa_intredge',no'le'in
         kernel config)
Date: Sun, 9 Feb 2014 05:02:00 +0900

 >  IMHO "le at bicc" means something like "le requires bicc" - and not
 >  the opposite.
 
 The meaning is defined by config(9), not based on human language.
 
 > But if it means, in fact, the opposite, then there's
 > something worthy a fix there, don't you think?
 
 I don't think so at all.
 
 "le at bicc" just means "le is attached under bicc" and
 "le might require some driver sources" per description of files.* files.
 All meanings are described in config(9) and related man pages.
 
 >  >  Furthermore, users don't have to disable unnecessary devices.
 >  >  I.e. I'd say it's operational error and "don't do that."
 >  
 >  Therefore what's the point of kernel configuration, if I'm supposed to
 >  leave everything that I don't need there?
 
 See below.
 
 If you don't know what's wrong you can leave them as is.
 If you want to solve problems in your own config file,
 you should learn about config(9).
 
 >  >  In the PR you wrote:
 >  >  >> 3. Comment out next two described lines - you'll see (in addition to 
 > the
 >  > former ones) very similar errors related to fwohci.
 >  >  and now you say remove one comment?
 >  
 >  Yes, to make it even easier for you to check, and to isolate the
 >  problem; just one line instead of two. It's enough to uncomment just
 >  this single line, and to try compilation. Did you verify?
 
 In your first report, you wrote "Comment out next two described lines"
 but they are already commented out in your MYKERNEL file.
 The description "next two described lines" was also vague.
 I enabled the two lines but no error.
 Then you wrote "remove comment of fwohci" later so it confused me.
 
 It's much simpler to provide exact config file that causes the problem
 rather than verbose descriptions without quoting.
 
 >  Unfortunately, you seem to ignore, that I'm describing the confusion,
 >  which is brought by messy description of the drivers' dependencies.
 
 What's your point that shouldn't be ignored?
 1) just want to know what's wrong
 2) config(1) should fail against inconsistent settings
 3) kernel build shouldn't cause link errors even with inconsistent settings
 4) config(9) should use more human instinctive grammer
 5) or something else?
 
 >  There is "le at bicc" - but I should know, that "it means the opposite
 >  as well". There is "fwohci* at pci?" - but I should guess, what else
 >  it needs for proper driver compilation, apart of pci switched on.
 
 You still don't mention what you exactly tried and what error you got.
 
 I just "guess" your problem is
  - you enabled "fwohci* at pci? dev ? function ?"
  - and disabled "ieee1394if* at fwohci?" and all its children
  - then got the following errors:
 ---
 fwohci.o: In function `fwohci_set_intr':
 fwohci.c:(.text+0x28b): undefined reference to `firewire_debug'
 fwohci.o: In function `fwohci_set_bus_manager':
 fwohci.c:(.text+0x644): undefined reference to `firewire_debug'
 fwohci.o: In function `fwphy_rddata':
 fwohci.c:(.text+0x793): undefined reference to `firewire_debug'
 fwohci.c:(.text+0x7ce): undefined reference to `firewire_debug'
 fwohci.c:(.text+0x814): undefined reference to `firewire_debug'
 fwohci.o:fwohci.c:(.text+0xe0f): more undefined references to `firewire_debug' 
follow
 fwohci.o: In function `fwohci_reset':
 fwohci.c:(.text+0xed1): undefined reference to `fw_linkspeed'
 fwohci.c:(.text+0xf4b): undefined reference to `fw_linkspeed'
 fwohci.c:(.text+0xfb4): undefined reference to `firewire_debug'
 fwohci.c:(.text+0x12fe): undefined reference to `fw_linkspeed'
 fwohci.c:(.text+0x1328): undefined reference to `firewire_debug'
 fwohci.o: In function `fwohci_arcv_swap.clone.5':
 fwohci.c:(.text+0x19a2): undefined reference to `firewire_debug'
 fwohci.o: In function `fwohci_db_free.clone.6':
 fwohci.c:(.text+0x19f6): undefined reference to `fwdma_free_multiseg'
 fwohci.c:(.text+0x19fe): undefined reference to `M_FW'
 fwohci.o: In function `fwohci_db_init':
 fwohci.c:(.text+0x1a67): undefined reference to `M_FW'
 fwohci.c:(.text+0x1aba): undefined reference to `fwdma_malloc_multiseg'
 fwohci.c:(.text+0x1c68): undefined reference to `fwdma_malloc'
 fwohci.c:(.text+0x1d0b): undefined reference to `M_FW'
 fwohci.o: In function `fwohci_irx_enable':
 fwohci.c:(.text+0x2132): undefined reference to `firewire_debug'
 fwohci.o: In function `fwohci_itxbuf_enable':
 fwohci.c:(.text+0x2727): undefined reference to `firewire_debug'
 fwohci.c:(.text+0x2836): undefined reference to `firewire_debug'
 fwohci.c:(.text+0x29d4): undefined reference to `firewire_debug'
 fwohci.o: In function `fwohci_start':
 fwohci.c:(.text+0x3052): undefined reference to `firewire_debug'
 fwohci.o:fwohci.c:(.text+0x30dc): more undefined references to 
`firewire_debug' follow
 fwohci.o: In function `fwohci_txd':
 fwohci.c:(.text+0x35d5): undefined reference to `fw_xfer_done'
 fwohci.c:(.text+0x3823): undefined reference to `firewire_debug'
 fwohci.c:(.text+0x38d8): undefined reference to `fw_xfer_done'
 fwohci.o: In function `fwohci_arcv':
 fwohci.c:(.text+0x3b12): undefined reference to `firewire_debug'
 fwohci.c:(.text+0x3e20): undefined reference to `fw_rcv'
 fwohci.c:(.text+0x40ef): undefined reference to `firewire_debug'
 fwohci.o: In function `fwohci_init':
 fwohci.c:(.text+0x45ac): undefined reference to `fwdma_alloc_setup'
 fwohci.c:(.text+0x45f0): undefined reference to `fwdma_alloc_setup'
 fwohci.c:(.text+0x4630): undefined reference to `fwdma_alloc_setup'
 fwohci.c:(.text+0x4874): undefined reference to `fw_init'
 fwohci.o: In function `fwohci_detach':
 fwohci.c:(.text+0x48f2): undefined reference to `fwdma_free'
 fwohci.c:(.text+0x491e): undefined reference to `fwdma_free'
 fwohci.o: In function `fwohci_intr':
 fwohci.c:(.text+0x4d2d): undefined reference to `firewire_debug'
 fwohci.c:(.text+0x552e): undefined reference to `fw_busreset'
 fwohci.c:(.text+0x5693): undefined reference to `M_FW'
 fwohci.c:(.text+0x5722): undefined reference to `fw_drain_txq'
 fwohci.c:(.text+0x5735): undefined reference to `fw_sidrcv'
 fwohci.c:(.text+0x573d): undefined reference to `M_FW'
 fwohci.o: In function `fwohci_resume':
 fwohci.c:(.text+0x592e): undefined reference to `firewire_resume'
 ---
 right?
 
 In this case, the "firewire_debug" symbol in the error message is
 declared in sys/dev/ieee1394/firewire.c and it's enabled only if
 "ieee1394if" is enabled as defined in sys/dev/ieee1394/files.ieee1394:
 http://nxr.netbsd.org/xref/src/sys/dev/ieee1394/files.ieee1394
 There is no pci related problem as there is no isa problem
 in the bicc at isa case.
 That's what "exact error messages in reports" can provide.
 
 The problem here is that parent devices assume that
 there is at least one required child device and
 implicitly refer symbols used/pulled by the children.
 We can avoid such link errors to disable such all references
 by dumb #if NFOO > 0 / #endif wrappers, but it provides
 ~no benefits to users as I wrote in the previous mail.
 
 If you just want to continue to edit your favorite config files,
 you only have to know two simple rules:
 
 - If you disable a parent device, you have to all child devices,
   otherwise config(1) complains "foo at bar is orphaned".
 - If you disable leaf devices, don't leave their parent devices
   without children, otherwise it could cause link errors during builds.
 
 Then you can see leaving parents ("bicc at isa" or "fwohci at pci")
 without children ("le at bicc" or "ieee1394if at fwohci") could be
 problematic.
 
 ---
 Izumi Tsutsui