Date: Wed, 10 May 1995 00:12:10 -0700 From: "Justin T. Gibbs" <gibbs@estienne.CS.Berkeley.EDU> To: terry@cs.weber.edu (Terry Lambert) Cc: rgrimes@gndrsh.aac.dev.com, brian@MediaCity.Com, freebsd-hackers@FreeBSD.org Subject: Re: A question of downloading device drivers Message-ID: <199505100712.AAA17329@estienne.cs.berkeley.edu> In-Reply-To: Your message of "Tue, 09 May 1995 20:07:42 MDT." <9505100207.AA20621@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>The developer. Note I did *not* say "a bad choice"... I render no >judgment other than to note that the static inclusion of that code >in binary form puts kernels distributed with it under obligation >to the GPL as long as it remains GPL'ed code. For the CDROM >distribution, this isn't a problem, but FTP code could be. Uhhh... Its not under the GPL any more Terry. > >> >A proof, I offer the fact the the darn things boot and run DOS without >> >any special software being necessary. >> >> Offer the technical specs for the interface to the default microcode >> and you offer an alternative (asuming we don't have VM86). Until then, >> there is no choice to be made. The board must be running microcode that >> we know the interfaces too in order for the kernel driver to talk to the >> board. The only way we can guarantee that now is by downloading our own >> from the get-go. > >Actually, that should be "assuming no one bothers to port NetBSD's VM86". > >I find the idea of importing NetBSD kernel code less abhorent than >importing GPL'ed code into the kernel, with all the baggage that >entails. Uhhh... Its not under the GPL any more Terry and I believe that the VM86 code is already being looked at by Nate. I don't think many people here would reject VM86 just because the code came from NetBSD. >I'm sure that someone with an AIC7770 based card finds booting less >abhorrent than arguing about distribution. 8-). > >On the other hand, Adaptec is willing to document *not requiring a >non-disclosure agreement* the default interface. It's in their >programming DOC for the card alone. They have a one page state diagram of how the sequencer should operate. They don't document the interrupt register codes their microcode uses (they are entirely free-form and up to the microcode developer) nor do they tell you where to set the program counter when you want to request sense since, according to there of so great documentation of the "default interface", the kernel driver is responsible for this jump (not how its done in FreeBSD). There is also no documentation about what actions the kernel driver is responsible for when handling extended SCSI commands. In short, they don't tell you any of the details you need to write the driver! How do I know this? I have in my possession all of the data books for these cards, I've written microcode for these cards, and I wrote FreeBSD's driver for these cards. >Failing that, the INT 13 and INT 21 >BIOS is available for disassembly if you have the card installed. Now I could have dissasembled the code, but since there are three different versions of the microcode out there with slightly different interfaces (they enfore BIOS and microcode updates at the same time) for the 274x series alone, it is not an option. Now stop saying that it is until you go make it work. The current microcode works fine, but if kernel bloat becomes a big issue and we get VM86 mode disk driver support, we can look at loading this during boot from a separate file. > Terry Lambert > terry@cs.weber.edu >--- >Any opinions in this posting are my own and not those of my present >or previous employers. -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ==============================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505100712.AAA17329>