Agree, until that becomes a problem I don't see a reason to rip it out
of SCSI.
> > > b. the host adapter is out of resources for *all* its devices. Block
> > > all device queues until we free some resources (again, usually a
> > > returning command).
> >
> > This is harder, because it involves more than one specific queue.
>
> Yes, this is our nastycase, especially for locking and ref
> counting...you didn't say I only had to hand off the easy problems,
> though...
:)
I really think this should be handled in the SCSI layer. You are dealing
with devices hanging off a hardware unit of some sort.
It's also possible to go too far with this whole abstraction deal. The
resulting code ends up being contorted, instead of having to separate
'straight forward' cases in SCSI and XYZ (for instance).
> Hotpluggin has to have some awareness of this locality too. Even for
> IDE, hot unplug a card and you can lose two devices per cable.
Hmmm yes. Now we are moving into general device management, though.
> > > 5. There needs to be some amalgam of the SCSI code for dynamic tag
> > > command queue depth handling.
> >
> > Again, block layer queueing was designed for what I needed (ide tcq) and
> > no overdesign was attempted. If you describe what you need, I'd be very
> > happy to oblige and add those bits. Some decent depth change handling, I
> > presume?
>
> Pretty much yes, now. We lost all of our memory allocation nightmare
> problems when we moved away from fixed command queues per device to lazy
> command allocation using slabs.
Alright, so what do you need? Start out with X tags, shrink to Y (based
on repeated queue full conditions)? Anything else?
-- Jens Axboe- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/