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

[Zbigniew <zbigniew2011%gmail.com@localhost>]

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

From: Zbigniew <zbigniew2011%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/48579: #34490 (kernel compile fails in 
`le_isa_intredge',no'le'
 in kernel config)
Date: Sat, 8 Feb 2014 19:07:01 +0100

 2014-02-08 18:45 GMT+01:00, Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>:
 
 >  >  But could you, please, tell me: how the user is supposed to know, that
 >  >  "bicc requires le" in NetBSD's kernel configuration?
 >
 >  IMO users who will edit kernel config are suppored to notice
 >  the "le at bicc" line has a parent "bicc at isa" line.
 
 IMHO "le at bicc" means something like "le requires bicc" - and not
 the opposite. But if it means, in fact, the opposite, then there's
 something worthy a fix there, don't you think?
 
 >  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?
 
 In NetBSD handbook you'll find: "Most NetBSD users will sooner or
 later want to recompile their kernel, or compile a customized kernel.
 This might be for several reasons". Well, if it is supposed to be done
 "sooner or later" - and you, developers, realize this - IMHO it can be
 even difficult, but it shouldn't be confusing, right?
 
 >  >  >  >  And what about strange FireWire driver problems?
 >  >  >
 >  >  >  I can't reproduce any problem, probably due to differnt procedures.
 >  >
 >  >  The procedure is rather simple:
 >  >
 >  >  In the kernel configuration file - the one I sent - remove comment
 >  >  from beginning of the line:
 >  >
 >  >  #fwohci* at pci? dev ? function ?       # IEEE1394 Open Host Controller
 >  >
 >  >  There won't be any error during "config MYKERNEL" neither "make
 >  >  depend" stages - but the compilation will fail with several
 >  >  "fwohci"-related errors.
 >
 >  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?
 
 >  >  The problem is, it is marked as pci?-dependent only (which is
 >  >  "switched on" already). My guess is, it needs another unrelated driver
 >  >  included into config, which pulls some header files - right? Which
 >  >  one?
 >
 >  If your claim is "kernel builds shouldn't fail if config(1) doesn't fail
 >  even if only parent devices are enabled" it would be ideally correct,
 >  but less worth to fix for me in these devices (unless patches are
 > provided).
 >  In that case, the kernel will just say "ieee1394if is not configured"
 >  after the parent fwohci is attached and users can't use the target
 >  devices anyway.  It would be rather worse than link errors on build.
 
 Unfortunately, you seem to ignore, that I'm describing the confusion,
 which is brought by messy description of the drivers' dependencies.
 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.
 -- 
 regards,
 Zbigniew