[7172] in linux-scsi channel archive
Re: Fixing the SCSI layer
daemon@ATHENA.MIT.EDU (Matthew Jacob)
Mon Sep 6 17:58:45 1999
Date: Mon, 6 Sep 1999 14:56:30 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
Reply-To: mjacob@feral.com
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
cc: tad-m2n@omoikane.co.jp, groudier@club-internet.fr,
linux-scsi@vger.rutgers.edu
In-Reply-To: <E11O6eZ-0000N6-00@the-village.bc.nu>
> > In short, correct scheduling policy is set by the overall system with
> > per-bus information being only one factor in the equation.
>
> yes - you need information from both. But at that point I don't buy your
> argument. The HBA can check resource status just as well as the midlayer
> can ask the HBA. Furthermore if the HBA wants to do something wacko for
> good reasons (eg if it has hidden private resources) it can do so if
> its in charge. So the HBA has to be able to consult the midlayer and
> set policy to reflect HBA variances.
>
> We have 50 HBA's one midlevel, so HBA's can handle midlevel hints more
> easily that the midlevel having to be tuned for 50 conflicting requirements
Umph. Yes- this is possibly true. I think this may be more of a design
philosophy issue. With your approach, you will possibly end up with an
unpredictable OS platform- at the mercy of J random HBAs. With the
approach I tend to prefer, you force the HBAs to use a midlayer which may
be more consistent (but more difficult to abstract sanely for widely
different HBAs). Sigh- it's just for this reason that Larry McVoy has
always thought me a bit of a nitwit...
-matt
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
