Date: Thu, 13 Feb 1997 00:02:34 +0100 (MET) From: Wolfgang Helbig <helbig@MX.BA-Stuttgart.De> To: se@freebsd.org (Stefan Esser) Cc: hackers@freebsd.org Subject: Re: CMD640b workaround - final(?) version Message-ID: <199702122302.AAA00343@helbig.informatik.ba-stuttgart.de> In-Reply-To: <19970212213157.YA20116@x14.mi.uni-koeln.de> from Stefan Esser at "Feb 12, 97 09:31:57 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Esser wrote > On Feb 11, helbig@MX.BA-Stuttgart.De (Wolfgang Helbig) wrote: > > If you use the > > options "CMD640" > > you also *have* to put > > controller pci0 > > into your configuration file! Maybe someone can put the right clauses > > in /sys/conf/files to automaticly resoving this (ugly) dependency! > > Ahemm ? > What I wanted to be achieved by changing /sys/conf/files is: If you put options "CMD640" in your kernel configuration file you will automatically get the pci-code included and started in the kernel, even if you don't put the controller pci0 line in the configuration file. Since I do not grasp the workings of /sys/conf/files and /sys/i386/conf/files.i386, I don't know whether this is possible. Now suppose a newbie has installed successfully FreeBSD on a machine with the CMD640b-controller, (because the generic kernel does have options "CMD640" and controller pci0). He does not even know, that he has something special, because he used the same machine with Windos and LINUX before and didn't have any trouble. (ok, the newbie is me :-) ) Now he want's to build a customized kernel. He will find out that he needs the CMD640b option (as I would have found out) and that he does not need the pci-controller code, because it does not do any good. (That is the way I proceeded. I did not have the pci-code in my kernel.) So now if you leave the definition of cmd640_detected in pci.c our newbie will get a link error. If you put this definition in wd.c, our newbie will not get a link error but the kernel will freeze after the first attempt to use both ide-channels simultaneously. I believe the second perspective is worse, because it is harder to recover and early detected errors are less harmful in general. > The CMD640 option obviously makes no sense on a system > without a PCI bus. But I agree, that it violates the But a kernel w/o pci-support *does* make sense on a system with PCI bus, because the pci-code is simply overhead if no pci-drivers get installed. > principle of least surprise, if this option causes a > kernel build to fail for a non-PCI system (without the > controller pci0 line). > > > There are 2 possible workarounds: > > 1) Include pci.h into the wd driver, and #undef CMD640, > if NCPI == 0. > > 2) Move the definition of "cmd640_detected" into wd.c, > and make the PCI probe code use it as an *external* > variable only if CMD640 is defined. > > > BTW: I do heavily dislike the way you introduced the PCI > ID of the CMD640 into pci.c, and will not accept it! > > There is NO device specific code in pci.c for a reason! BTW: My solution is simpler. For a reason! I do heavily dislike complicated code if there is a simpler way! Do whatever you want with it, I will accept it! Wolfgang Helbig.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702122302.AAA00343>