Date: Tue, 11 Jan 2000 00:48:16 +0100 (MET) From: Gerard Roudier <groudier@club-internet.fr> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: Matthew Jacob <mjacob@feral.com>, Peter Wemm <peter@netplex.com.au>, obrien@NUXI.com, "Chris D. Faulhaber" <jedgar@fxp.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf GENERIC LINT Message-ID: <Pine.LNX.3.95.1000111001821.759A-100000@localhost> In-Reply-To: <200001102230.OAA22842@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.1000111001821.759A-100000>