Re: Just a couple of things.

[miff@asharak.apana.org.au (michael smith)]

In <9404271422.AA20250@hpbeo79.bbn.hp.com> you wrote :

>> Well, at least with source code to the CBHD driver, we would be able
>> to make such a driver. Making the driver respond to interrupts instead
>> of polling can't be that big a problem. At least not when all the
>> scsi setup code can be ripped off this driver. How much work it will
>> be to setup the queues of processes wanting to do IO under MiNT 
>> I won't comment on.
>
>It's certainly not trivial to get all debugged, but it's not the
>biggest issue. We need kernel reentrancy first, that's the main
>problem.

Bingo!

While we are talking about all this, and people are writing lots of code
to talk to the SCSI port(s)...

Can we _please_ have a low-level SCSI driver that knows _nothing_ about 
filesystems or disks or anything like that?

And (just to really make your day) one that can be both requestor and target.
You could add disconnect and command queueing too.

Why, you ask?  Well, the alternative will be to _poll_ some non-disk SCSI
devices (can you spot someone who's actually working on his mythical 
ethernet box? 8), which won't do much for system performance.

I have spent many hours wondering how I was going to have the box interrupt
the atari, and now I know 8).

>From the software side, it would be ideal if 

:  The low-level code kept a table of the device identify pages

:  It were possible for multiple drivers to register interest in 
   interrupts from a given ID (don't ask 8)

Probably more thoughts as I get deeper into things, but that should
keep you busy for now 8)

>Claus Brod, MDD, HP Boeblingen         Have you hugged your manager today?

BTW Claus, loved the book 8) (does the latest CBHD do TT-scsi as well?)


--
--
mike smith : silicon grease monkey  | If you think it can't be done, |
miff@asharak.apana.org.au           | it means you don't have enough |
miff@apanix.apana.org.au            | money in your budget.          |