All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Wilck <martin.wilck@suse.com>
To: "bmarzins@redhat.com" <bmarzins@redhat.com>
Cc: "dm-devel@redhat.com" <dm-devel@redhat.com>,
	Hannes Reinecke <hare@suse.com>
Subject: Re: [dm-devel] [PATCH 2/4] libmultipath: fix priorities in parse_vpd_pg83
Date: Mon, 29 Mar 2021 19:08:14 +0000	[thread overview]
Message-ID: <facc763d175793d4d21822f8880522574364680a.camel@suse.com> (raw)
In-Reply-To: <20210329182033.GJ15006@octiron.msp.redhat.com>

On Mon, 2021-03-29 at 13:20 -0500, Benjamin Marzinski wrote:
> > 
> > multipathd could figure out the system configuration from the (non)
> > availability of certain properties, and use an appropriate fallback
> > logic for either case.
> 
> That seems like reasonable first step, although one that won't help
> SID,
> since it can't rely on getting the wwid from udev. 

Can you conceive of a different approach that would be better for SID?
I'd like to hear about it.

>  This actually brings
> up a different point I have. Is your main objection to adding more
> config options that it is complicating the code, or confusing the
> users?

Both, with emphasis on the latter. I'm quite positive that we have too
many options already. That doesn't mean I would generally oppose new
options if they make sense. We should rather try to get rid of some new
ones that nobody uses any more.

> Because multipath wouldn't need to add any configuration options to
> be
> easily usable with SID (the current workaround, setting uid_attribute
> to
> "", is pretty non-obvious to users) if it could just check if sid was
> running, and key off that.  However this adds even more code
> complexity
> than simply checking a config option. I don't know how you would feel
> about accepting a patch that does this, when SID is production ready.

I could live well with this autodetection. I think it would be better
than doing the same thing with a configuration options.

Regards,
Martin


-- 
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix Imendörffer



--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


  reply	other threads:[~2021-03-29 19:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26  0:52 [dm-devel] [PATCH 0/4] Fixups to my wwid recheck patch Benjamin Marzinski
2021-03-26  0:52 ` [dm-devel] [PATCH 1/4] libmultipath: avoid infinite loop with bad vpd page 83 identifier Benjamin Marzinski
2021-03-26 16:49   ` Martin Wilck
2021-03-26  0:52 ` [dm-devel] [PATCH 2/4] libmultipath: fix priorities in parse_vpd_pg83 Benjamin Marzinski
2021-03-26 17:12   ` Martin Wilck
2021-03-27  2:18     ` Benjamin Marzinski
2021-03-29  8:44       ` Martin Wilck
2021-03-29 18:20         ` Benjamin Marzinski
2021-03-29 19:08           ` Martin Wilck [this message]
2021-03-29 20:09             ` Benjamin Marzinski
2021-03-29  8:47   ` Martin Wilck
2021-03-26  0:52 ` [dm-devel] [PATCH 3/4] multipathd: improve getting parent udevice in rescan_path Benjamin Marzinski
2021-03-26 17:15   ` Martin Wilck
2021-03-26  0:52 ` [dm-devel] [PATCH 4/4] multipathd: don't trigger uevent for partitions on wwid change Benjamin Marzinski
2021-03-26 17:16   ` Martin Wilck

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=facc763d175793d4d21822f8880522574364680a.camel@suse.com \
    --to=martin.wilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=hare@suse.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.