From owner-cvs-all Mon Jan 10 11:46: 6 2000 Delivered-To: cvs-all@freebsd.org Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by hub.freebsd.org (Postfix) with ESMTP id E98A615350; Mon, 10 Jan 2000 11:45:54 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-168-249.villette.club-internet.fr [195.36.168.249]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id UAA06089; Mon, 10 Jan 2000 20:44:54 +0100 (MET) Date: Mon, 10 Jan 2000 21:12:35 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost Reply-To: Gerard Roudier To: Matthew Jacob Cc: Peter Wemm , "Rodney W. Grimes" , obrien@NUXI.com, "Chris D. Faulhaber" , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf GENERIC LINT In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Sun, 9 Jan 2000, Matthew Jacob wrote: > > On Sun, 9 Jan 2000, Matthew Jacob wrote: > >=20 > > > > Hmmm... In fact this patch hasn't the expected effect :). I didn't = provide=20 > > > > a better one since nobody seems to need to configure both drivers. > > >=20 > > > Don't both drivers have to configured in the GENERIC case? > >=20 > > Only the support for the C1010 requires both driver to be configured=20 > > in GENERIC since it is the kernel that will be used for installation. > >=20 > > For now, my understanding of the situation is: > >=20 > > 1) 4.0 has appropriate flags to deterministically know about the driver= =20 > > the kernel will use for each 53c8xx chip when ncr and sym are > > configured. > > 2) next release is 4.0 > > 3) 3.4 is out of the door without the sym driver. >=20 > But the sym driver is in the RELENG_3 branch, so one way or the other an > INSTALL kernel will be built in 3.X with the sym driver. I am quite aware of that. > > 4) It has been reported that the actual order drivers are probed > > relies on /conf/files order and this probably will not change = in=20 > > later 3.X kernels until 4.X will be preferred by users. > >=20 > > If (4) is ok, then no need to go with a patch, in my opinion. If (4) is > > untrue, some tiny patch, similar to the one that had been proposed, > > applied to one of the driver should fit. If the sym driver has to be > > modified, this will not make problem. But a clear decision has to be > > taken, and I am waiting for this to occur. >=20 > I believe that if there is support for both SYM and NCR drivers, than for > whatever release they are integrated in they should *by default* not > overlap in device support (that's a problem with NCR, not SYM). If some > users wish to exclusively use NCR instead of SYM, say for an 83c75, a > config option to re-enable this support is appropriate. We only shall be able to tell user what driver will be used for each chip= =20 given a configuration, in my opinion. =20 > In either case, NCR needs to be modified so sanity happens. The trouble i= s > that the nominal owner of NCR, Stefan Esser, doesn't seem to be involved > here- otherwise any one of you, David O'Brien, Me, Rodney, whomever, can > just do the right thing. I feel myself quite involved also in the ncr. The fact that I haven't yet proposed any change for this driver is because I have limited time. My proposal about ncr/sym coexistence can be illustrated by the following= =20 minute diffs (quite untested and incomplete). --- sym_hipd.c=09Sat Jan 8 11:56:02 2000 +++ sym_hipd.c.SUGGEST=09Mon Jan 10 20:44:09 2000 @@ -9712,7 +9712,11 @@ =09struct=09sym_pci_chip *chip; =20 =09chip =3D sym_find_pci_chip(pci_tag); +#if NNCR > 0 +=09if (chip && !(chip->lp_probe_bit & SYM_SETUP_LP_PROBE_MAP)) +#else =09if (chip) +#endif =09=09return chip->name; =09return 0; } This patch tells the sym driver to _not_ attach some given 8XX devices based on the _same_ map that works as low priority in 4.0, when ncr is also configured. This gives about the _same_ functionnality _as_ 4.0 regarding determination of the actual driver that will attach devices.=20 But, the 895A and 1510D devices are to be added to the ncr device table, otherwise these devices will not be attached by the ncr if the sym is=20 told to ignore them (btw, the ncr is able to cope with them given appropriate entries in its device table). With such a change, for example: SYM_SETUP_LP_PROBE_MAP=3D0 makes the sym take precedence SYM_SETUP_LP_PROBE_MAP=3D7 makes the ncr take precedence If my proposal gets accepted, I will prepare the corresponding changes. I also want to document them in the sym man page I intend to write asap=20 (modulo the time I will have for that). Could people that are interested in that topic let me know if they agree=20 or not with my proposal. Thanks. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message