From: julian@tfs.com (Julian Elischer)
Newsgroups: comp.unix.bsd
Subject: New scsi driver.
Date: 22 Aug 92 22:00:06 GMT
Distribution: comp
Organization: TRW Financial Systems

Well I have finally had time to port some of my SCSI stuff to 386bsd.
I have the adaptec driver working and the generic tape subdriver
seems to find the tape on the scsibus and attach to it.
I don't know if the actual reads and writes work yet as there is
no tape in  the drive (which is at work, and I am at home)
But I have no reason to doubt it so far.

I have a couple of questions which maybe some people out there can
answer to save me time:

1/ ddb uses strcmp (as I do) The only strcmp in the kernel is
in ddb, so if I don't include ddb, I can't link. Does anybody have 
any knowledge of a similar function in the kernel by default.
(I have done all sorts of greps but can't find one).
I may end up taking strcmp out of ddb and make it generic.
(I note there IS a strncpy)

2/ The MACH and OSF kernels have a function
spinwait(millisecs) and a calibrated delay counter
delaycount that is used by spinwait() and set up when the clock is
started.. Does anybody know of such a 'calibrated count variable'
for 386bsd. (i.e a loop of that variable number of times takes the
same amount of time on any kind of machine.) I have just put a constant
into a local copy at the moment, (I use it to loop in timeouts in 
the probe, before the interrupts are usable.) but a constant is not
very portable. I may just port in the routines from mach.

For those that don't know why my scsi stuff is different to
the existing stuff, this may help:

+------+    +-------+    +-------+    +-------+
| tape |    | disk  |    | cdrom |    | your  |
|      |    |       |    |       |    |device |
+------+    +-------+    +-------+    +-------+
                                                 
+-------------+                                    
| Autoconnect |                                   
| scsi probe  |                                    
| module      |                                    
+-------------+                                    
                                                 
+-------+    +-------+    +-------+    +-------+
|adaptec|    |bustek |    |your   |    |adaptec|
|1542   |    |742    |    |adapter|    |1740   |
+-------+    +-------+    +-------+    +-------+

Any device could be on any adapter and in fact
a single type of device may be present on each
of several different types of adapters simultaniously

The scsi ID's of the devices need not be known at kernel
build time but are dynamically probed out and 'attached'
to their correct drivers at boot time.
(there is a mechanism for preattachind devices you think may
be turned off at boot time)
I hope to be able to release an alpha version of the system
at the middle or end of next week.
(btw the 1740 driver is not written yet but I have received the manual!)


 notice people asking for in2000 drivers and dtc drivers etc.
 with this scheme it should be possible to add the drivers for
 these boards without having to write new scsi disk and tape and 
 configure code.

+----------------------------------+       ______ _  __
|   __--_|\  Julian Elischer       |       \     U \/ / On assignment
|  /       \ julian@tfs.com        +------>x   USA    \ in a very strange
| (   OZ    ) 2118 Milvia st. Berkeley CA. \___   ___ | country !
+- X_.---._/  USA+(510) 704-3137(wk)           \_/   \\            
          v
Newsgroups: comp.unix.bsd