Date: Wed, 12 Feb 1997 21:31:57 +0100 From: se@freebsd.org (Stefan Esser) To: helbig@mx.ba-stuttgart.de (Wolfgang Helbig) Cc: hackers@freebsd.org Subject: Re: CMD640b workaround - final(?) version Message-ID: <19970212213157.YA20116@x14.mi.uni-koeln.de> In-Reply-To: <199702112257.XAA01704@helbig.informatik.ba-stuttgart.de>; from Wolfgang Helbig on Feb 11, 1997 23:57:44 %2B0100 References: <199702112257.XAA01704@helbig.informatik.ba-stuttgart.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ? The CMD640 option obviously makes no sense on a system without a PCI bus. But I agree, that it violates the 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! Please take a look at if_ed_p.c for a trivial PCI probe and attach example. In fact, your atatch code will just be "return wd_attach (.., .., /* cmd640_present = */ 1)" and you will have to modify the attach function in wd.c to accept that additional parameter ... (In fact, I'd rather make it an "eide_implementation" parameter, which is an enumeration of all the chips that may be supported by this mechanism at a time :) Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970212213157.YA20116>