Date: Tue, 11 Jan 2000 13:13:49 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: groudier@club-internet.fr (Gerard Roudier) Cc: mjacob@feral.com (Matthew Jacob), peter@netplex.com.au (Peter Wemm), obrien@NUXI.com, jedgar@fxp.org (Chris D. Faulhaber), cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/conf GENERIC LINT Message-ID: <200001112113.NAA25491@gndrsh.dnsmgr.net> In-Reply-To: <Pine.LNX.3.95.1000111211445.380A-100000@localhost> from Gerard Roudier at "Jan 11, 2000 10:05:06 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
... > > The adaptec collection are far more different from each other than the > > 2 most different sym chips. The ahc driver supports the family of > > chips that is compariable to the sym driver, yes it is a complex beast, > > but so is maintaining 2 sets of code that are 80% similiar in functionality. > > I was _obviously_ joking there. I know a bit about adaptec controllers > collection, by the way. :-) > > What is so different about the 810, 815 and 825 chip that they need thier > > own driver that will need maintained for at least 5 more years? > > The 810, 815 and 825 have a poor SCRIPTS instruction set. Even a years-60 > PDP-8 was better on this topic. Basically you must do everything using > memory copy, make the chip perform PCI self mastering and have to use self > modifying code with 810, 815 and 825. The new LOAD/STORE instructions > allow to write SCRIPTS that are a lot more clean. Thanks to these > instructions, the sym driver, for example: > > - Ensures PCI 2.2 compliance (no self mastering through the PCI BUS) > - Does not use self modifying code. > - Have very fast paths that uses 0(n) table look-up from SCRIPTS. > - Has all SCRIPTS running from on-chip RAM for chip having 8K on-chip RAM. > (896, 1510D, 895A, 1010) Thats what I needed to know. So now I have more questions. Does it make since to gut the ncr driver down so that it only supports the 810/815/825 and/or write a sym_xxx based on your driver only using a different SIM layer or ??? Would it simplify the ncr.c driver code to drop support for the more advanced cards that are well supported by the sym_hipd driver? > > The equivalent generic SCRIPTS (using MEMORY COPY) that would allow to > implement similar design as the sym uses can only look like a pile of > crap, in my opinion. Could one driver handle 2 SIM layers? Use a dispatch table to change how the routines work. The operational events should be similiar, just the underlying interface is different right? > > My choice has been to go with 2 drivers for reasons that appeared fully > _valuable_ to me. I also elected to go with 2 free O/Ses. People who wants > to do different or better are as free as I am to do what they want. :-) > If there is a place where things must _NOT_ be generic in CAM, it is the > SIM layer. The LOAD/STORE instructions appeared to me as a major > difference that suggests to have 2 differents SIM for the 53C8XX family. > The more time goes, the more I feel I have been right. I'll print vgrind copies of the sym and ncr driver and have a read to update my brain on what has changed. Last time I read the ncr code was over 4 years ago.... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net 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?200001112113.NAA25491>