All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: christophe varoqui <christophe.varoqui@free.fr>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: multipath-tools Makefile
Date: Wed, 20 Jun 2007 08:13:28 +0200	[thread overview]
Message-ID: <4678C588.3030606@suse.de> (raw)
In-Reply-To: <1182288865.20149.259.camel@localhost.localdomain>

Christophe Varoqui wrote:
> Le mardi 19 juin 2007 à 14:25 -0700, Chandra Seetharaman a écrit :
>> On Tue, 2007-06-19 at 23:15 +0200, Christophe Varoqui wrote:
>>> Le lundi 18 juin 2007 à 17:57 -0700, Chandra Seetharaman a écrit :
>>>> Hi,
>>>>
>>>> Sorry about the late response. I just realized that pp_rdac has been
>>>> added to the multipath tree.
>>>>
>>>> pp_rdac is not needed to support lsi-rdac devices. pp_tpc performs
>>>> equally good. I repeated my tests with pp_tpc and they did work well.
>>>>
>>> rdac has superseded the tpc checker in the upstream tree.
>>>
>> (A):
>>> This checker is currently the only one usable with LSI Engenio hardware
>>> integrated by either IBM or SGI. As such I don't plan on removing it
>>> from the tree, if it's ok with you.
>>>
>> I am little confused here.
>>
>> Background info:
>> ------
>> (1) When I said we do _not_ need pp_rdac, I am referring to path
>> priority callout code(the code I submitted on May 21st). Code under the
>> directory path_priority/pp_rdac.
>>
>> (2) The path checker code I submitted on March 23rd is needed to support
>> the LSI Engenio hardware. This code resides in libcheckers/rdac.c
>> ------
>>
>> (2) is needed and I presume you are referring to that at (A) 
>>
>> (1) is not needed and we can achieve the same with
>> path_priority/pp_tpc/mpath_prio_tpc
>>
> 
> The confusion was on my side, thank you for pointing it.
> I'll get back to my homework then.
> 
Or we finally resolve this issue by renaming pp_tpc to pp_rdac.

pp_tpc is sadly a misnomer as it was originally developed against SGI
TPC arrays, of which I only had insufficient documentation.
Only later I found out that this was actually a RDAC controller.

Christophe, go.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

      reply	other threads:[~2007-06-20  6:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-18 22:59 multipath-tools Makefile bmarzins
2007-06-19  0:57 ` Chandra Seetharaman
2007-06-19 21:15   ` Christophe Varoqui
2007-06-19 21:25     ` Chandra Seetharaman
2007-06-19 21:34       ` Christophe Varoqui
2007-06-20  6:13         ` Hannes Reinecke [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4678C588.3030606@suse.de \
    --to=hare@suse.de \
    --cc=christophe.varoqui@free.fr \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.