On Mon, 31 Aug 1998, Markus Baeurle wrote:

> You're not doing anything wrong.
> The Cumana driver used to be part of RiscBSD pretty much from the beginning.
> But it was always under NDA so the source didn't become part of the NetBSD
> source tree.
> When the NDA was finally withdrawn about half a year ago, Mark decided not to
> make it part of the NetBSD tree because it is using an older, modified
> version of the chip-specific part of the driver. It don't see the point as
> other drivers such as the one for the Powertec also do this, but he's the one
> who decides.
Currently a private arm32 specific patched version of the NCR has not been
added. The powertec in the tree uses the older sfas code. The motivation
for not committing it was that it is better and cleaner to make things
work with the existing MI driver, that however requires time which is a
commodity in very short supply ;-(

> He gave me the source code and for some time I've been trying to get it to
> work with the up-to-date, machine-independant version of the chip-specific
> layer. But I'm pretty much stuck here. I will keep trying but I don't have
> much knowledge of kernel internals or the SCSI system, so I can only try.

How far have you got so far ? Do you have ay code you can throw my way to
look at ?

> Possible solutions for you?
> 1) I have a pretty up-to-date kernel (current sources from August 9) that I
> can make available. Talking of podules and such, it has pretty much
> everything removed other than Cumana SCSI II and NE2000 ethernet, though.
> No IDE, no other podules, no NFS server, ...
> 2) I succeed to move the driver to the current version, so it becomes part of
> the tree and all future kernels will have Cumana SCSI II support at last. But
> I can't tell you when this could happen - see above.
> 3) Mark checks in the driver although it doesn't use the current version yet.
> Otherwise, same as 2).

Ok since this is a problem that needs addressing and I have not been able
to do it the way I wanted due to time I need to find some stop-gap
solution at least. I have a verison of the cumana driver that uses the
older sfas code so I will put this in the tree. (I don't have a cumana
card to test with myself)

This should then at least allow installs etc. from the cumana card.

Markus: If I get something in the tree and send you a kernel, any chance
you could confirm that it appears to work ?

Cheers,
				Mark