That depends, between 0 and some, depending on that the IO Subsystem
needs. Most of the current supported controllers, ie. NCR, Buslogic,
Adaptec etc. are all simple minded creatures that could share a generic
code like they currently do. This is nothing new and is standard in
standard in most proper operating systems.
> We already have a significant
> amount of bloat in the low level drivers as each one handles its own
> queueing responsibilities, etc. This would simply add more to that.
See above.
> Then, if you have someone such as myself who routinely has several
> different SCSI controllers compiled into their kernel, that code adds up.
So ? Memory is cheap. Do you want a fast and proper working IO subsystem
or do you want a creature like we have it today that breaks down whenever
there is the slightest thing that does not fit in the generic sheme that
was developed when THE high end controller with all top features was the
AHA1542 ? I don't think so.
> Not to mention that when you split things out of the mid level code this
> way, then you are talking about having the inherent problem of each driver
> having to get this timeout logic correct on their own. You would no
> longer have a generic scsi layer that (suppossedly) works, but instead you
> would have "This driver properly handles timeouts, this driver flakes out
> when a command times out" etc.
Look above. This is exactly what we have today. Because of this
the SCSI subsystem is only able to handle the streamline mass market
controllers.
> In truth, the only scenario you are bringing up that needs this kind of
> control is on a hardware RAID controller that does some kind of live
> rebuild for a lost device. Then you have the situation of having to wait
> on commands to complete because the controller is busy rebuilding that
> lost drive and handles your commands as it can. For non hardware-RAID
> controllers (the vast majority of those out there :) this wouldn't buy us
> anything since those controllers don't go around doing intelligent things
> on the SCSI bus behind our back.
This is exactly the problem, you will see more and more sophisticated and
intelligent controllers in the future, and their behaviour will divert
more and more from that of an AHA1542, basically the only thing that they
have in common is that they process SCSI commands SOMEHOW. Any assumptions
additionally to that will defintely lead to problems at some point.
The only place where strategic decisions can be done are in the lowlevel
driver. You can supply a set of generic routines for that for the current
set of streamline controllers but anything else is a fatal mistake.
Mike