From owner-freebsd-scsi Sun Jan 28 16:52:16 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA15477 for freebsd-scsi-outgoing; Sun, 28 Jan 1996 16:52:16 -0800 (PST) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA15448 for ; Sun, 28 Jan 1996 16:52:06 -0800 (PST) Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id BAA27791 for ; Mon, 29 Jan 1996 01:51:57 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id BAA13521 for freebsd-scsi@FreeBSD.ORG; Mon, 29 Jan 1996 01:51:57 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.7.3/8.6.9) id BAA05392 for freebsd-scsi@FreeBSD.ORG; Mon, 29 Jan 1996 01:47:57 +0100 (MET) From: J Wunsch Message-Id: <199601290047.BAA05392@uriah.heep.sax.de> Subject: Re: scsi cleanup To: freebsd-scsi@FreeBSD.ORG Date: Mon, 29 Jan 1996 01:47:56 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199601282202.OAA02211@ref.tfs.com> from "Julian Elischer" at Jan 28, 96 02:02:30 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk As Julian Elischer wrote: > > > [1995/03/28] kern/275 qic-02 streamer won't work > not really SCSI? Not SCSI. But i've got a donation of two drives (Wangtek and Archive), so i'll pick this up some time later. This looks like an ``extended weekend project''. :) > > [1995/06/18] misc/530 Failed install from SCSI tape > install error I think Nevertheless, our sysinstall should get an option to allow some basic settings that mt(1) does. I think of blocksize and perhaps density codes. Just for those oddball weird tape drives (or old firmware revs) where the drive misidentifies itself. Things are fine for a running system (you've got an rc.local there), but with sysinstall, you're sorta outta luck. > > get the SCSI reprobe code working properly on all host adapters. > > agreed. This requires that interrupts are fully set up > at the time of probing.. I'm not convinced of this.. Nope. I've once started to rewrite the code, but eventually gave up. It's necessary to pass the information down through all the layers whether the actual probe must be handled in polled mode (system initialization, dumping) or in interrupt mode. This can be done, but is a lot of work for the current architecture. > > Be sure you can work with the SCSI system even if only a host > > adapter was found at boot time. > I think this basically requires the existenc in a non-optional way > of the 'super-scsi' device or some equivalent. I think this would be fine. > > Get the CD-ROM writer code working. > joerg seems to have this under control. I'm really interested in a discussion of the approach i've been taking. I hope it's extensible enough. I don't really have a clue yet how to handle the case that a CD-R drive includes all the CD-ROM functionality. > > Fix it so you can use a 1542A. > > anyone have one? I've got a 1540A, but it works fine. It looks like only very early firmware rev's are affected. (I know of at least one other 1542A that works quite well, in this case with FreeBSD 2.1R, even at a customer of us. :) > I want to write more documentation about how it all goes together. > The code needs to have more comments put in it. Well, i'm more in favour of documenting the generic scsi functions in the newly-created section 9 of the manual. I don't think we need to write man pages for every oddball function in a device-specific driver, but it might be useful for the ``recyclable'' generic code. After all: Julian, though one needs a few sheets of paper to have hardcopies from some files, it has been possible at all to dig through the code, even in its current state. One needs hardcopies of the SCSI-2 specs, too, but that's probably the least the must be expected from a SCSI driver developer. I'd explicitly thank you and Peter for all your good work! My efforts with the worm driver wouldn't have been possible otherwise. p.s.: I think we are almost the first who can claim full support for a CD-R under multiuser conditions. :) (I could even fire up xdm and log into an X session while the burning was in progress.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)