From owner-cvs-all Mon Jan 10 15:23: 5 2000 Delivered-To: cvs-all@freebsd.org Received: from front7m.grolier.fr (front7m.grolier.fr [195.36.216.57]) by hub.freebsd.org (Postfix) with ESMTP id DE62F1539C; Mon, 10 Jan 2000 15:22:51 -0800 (PST) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-169-86.villette.club-internet.fr [195.36.169.86]) by front7m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id AAA24045; Tue, 11 Jan 2000 00:20:35 +0100 (MET) Date: Tue, 11 Jan 2000 00:48:16 +0100 (MET) From: Gerard Roudier X-Sender: groudier@localhost To: "Rodney W. Grimes" Cc: Matthew Jacob , Peter Wemm , 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: <200001102230.OAA22842@gndrsh.dnsmgr.net> 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 Mon, 10 Jan 2000, Rodney W. Grimes wrote: > > On Mon, 10 Jan 2000, Rodney W. Grimes wrote: [ ... ] > > And it works just fine. I just gave the tiny real changes below a try a= nd=20 > > all behaved as expected: >=20 > The only concern I have left is order of probes, but as long as no > one screws with the files file we should be okay. (Perhaps a comment > near the sym and ncr drivers in sys/conf/files would help? ) Yes. But even if order of files got changed, the breakage would probably=20 not harm. > > Index: sym_hipd.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /home/ncvs/src/sys/dev/sym/sym_hipd.c,v > > retrieving revision 1.2.2.1 >=20 > Looks good. Thanks. =20 > > This is pretty simple and avoids drivers to know too much about each > > another. We (I) only must guarantee that both drivers use kind of > > compatible chip tables which is easy to check and also to maintain give= n > > that the chip tables are unlikely to evolve very often and that we have= to > > ensure these tables to be actually fine with the _reality_ of the 53C8X= X > > chip family. If it happens that things ever went wrong, then either bog= us > > or incomplete the chip table of one of the drivers would be. > >=20 > > I donnot want to couple the driver sources more than the above patch does > > for the moment. Btw, under Linux the chip table is defined as a big macro > > and shared by both the ncr53c8xx and sym53c8xx driver, but both drivers > > scan the chip table the same way. We can ever also use a single chip ta= ble > > for the ncr and the sym, but it is not urgent and I donnot want to fall > > into the 'feature of the day' way of developing software that is known = to > > likely broke things rather than fixing them.=20 >=20 > Again I agree here. The only last thing that has me concerned is that > the ncr driver will now suffer serious bit rot due to lack of use. Any > chance of supporting the small collection of older chips from the ncr > driver in the sym driver so that ncr.c can just die? I care after such a zombie (linux ncr53c8xx) since 1 year now:). It is only maintained against bugs and O/S changes. Seems the ncr also lives this way since a couple a year. The sym driver supports from 810A to 1010 and does actually use as best=20 as I was able to do all features of these chips. Also supporting the old=20 chips would have add to much complexity, or victimize new chips, actual=20 reliability, etc... FYI, SYMBIOS has 1 driver for 810 up to 895 and another one for 896 to 1010 (may-be the 1010 will get a new driver, I donnot know). The sym only drops support for 6 years old chips.=20 By the way, possible it is to write a single SIM that supports all the Adaptec collection of SCSI boards. Any volonteer? ;-) G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message