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>
index | next in thread | previous in thread | raw e-mail
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 and > > all behaved as expected: > > 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 not harm. > > Index: sym_hipd.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/dev/sym/sym_hipd.c,v > > retrieving revision 1.2.2.1 > > Looks good. Thanks. > > 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 given > > 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 53C8XX > > chip family. If it happens that things ever went wrong, then either bogus > > or incomplete the chip table of one of the drivers would be. > > > > 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 table > > 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. > > 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 as I was able to do all features of these chips. Also supporting the old chips would have add to much complexity, or victimize new chips, actual 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. By the way, possible it is to write a single SIM that supports all the Adaptec collection of SCSI boards. Any volonteer? ;-) Gérard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.1000111001821.759A-100000>