From owner-freebsd-current Tue Mar 12 9:56:45 2002 Delivered-To: freebsd-current@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 2AE0737B429 for ; Tue, 12 Mar 2002 09:56:21 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.6/8.11.5) with ESMTP id g2CHwMI30008; Tue, 12 Mar 2002 10:58:22 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200203121758.g2CHwMI30008@aslan.scsiguy.com> To: "Kenneth D. Merry" Cc: Rasmus Skaarup , Poul-Henning Kamp , current@FreeBSD.ORG Subject: Re: GEOM code ready for testing In-Reply-To: Your message of "Tue, 12 Mar 2002 10:34:23 MST." <20020312103423.A79424@panzer.kdm.org> Date: Tue, 12 Mar 2002 10:58:22 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >FWIW, Justin and I have been thinking about (for years, actually) doing >multipath support inside CAM. Actually, the multipathing support would be in new-bus and CAM would be one newbus client able to detect redundant paths and register them accordingly. The main thing to remember is that there are lots of device types that want to export the concept of multiple paths. CAM and GEOM may implement different policies with those paths or the devices in question may not even be of interest to those two subsystems. This is why the support should be generic enough to be used by CAM, GEOM, and all of the uses to follow. With newbus, this becomes pretty trivial. Each device node has a method for enumerating its paths. CAM or GEOM or X new cool thing, can then devise their own policy to handle this information. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message