From: Benjamin Marzinski <bmarzins@redhat.com>
To: Martin Wilck <martin.wilck@suse.com>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>,
device-mapper development <dm-devel@lists.linux.dev>
Subject: Re: [PATCH 0/6] multipath-tools: Handle tableless DM devices
Date: Mon, 18 Nov 2024 16:14:57 -0500 [thread overview]
Message-ID: <ZzuuUTMJgFPWV16s@redhat.com> (raw)
In-Reply-To: <fbab2026d6850617f84da01c9c075f468295aa3b.camel@suse.com>
On Mon, Nov 18, 2024 at 12:18:20PM +0100, Martin Wilck wrote:
> On Fri, 2024-11-15 at 18:22 -0500, Benjamin Marzinski wrote:
> >
> > I'm not completely happy with the MAPINFO_ID_IF_FOUND flag. An
> > alternative would be to run a second libmp_mapinfo() call without
> > MAPINFO_MPATH_ONLY to grab the name, if the first failed with
> > DMP_EMPTY.
> > If people think that's a better way to solve this, I can rework those
> > patches.
>
> We could simply choose to always fill in this information if the
> the caller has requested it, without an additional input flag. It's not
> an expensive operation. Is there a reason not to do this?
Your comments in the code said that libmp_mapinfo() will not touch any
of the output parameters if it doesn't succeed. I didn't audit the code,
but I can certainly imagine a situation where you passed in pointers to
some varaibles that already had values and you didn't want those values
overwritten unless libmp_mapinfo() returned DMP_OK.
But I can go look and see if any callers would get messed up if name or
uuid got set, even when the found device didn't match.
-Ben
>
> Thanks
> Martin
next prev parent reply other threads:[~2024-11-18 21:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 23:22 [PATCH 0/6] multipath-tools: Handle tableless DM devices Benjamin Marzinski
2024-11-15 23:22 ` [PATCH 1/6] libmultipath: signal device with no table in libmp_mapinfo Benjamin Marzinski
2024-11-19 16:39 ` Martin Wilck
2024-11-19 20:33 ` Benjamin Marzinski
2024-11-20 8:49 ` Martin Wilck
2024-11-20 21:59 ` Benjamin Marzinski
2024-11-21 8:57 ` Martin Wilck
2024-11-21 18:00 ` Benjamin Marzinski
2024-11-15 23:22 ` [PATCH 2/6] multipath-tools tests: fix mapinfo tests Benjamin Marzinski
2024-11-15 23:22 ` [PATCH 3/6] libmultipath: fix removing device after failed creation Benjamin Marzinski
2024-11-18 11:21 ` Martin Wilck
2024-11-18 21:23 ` Benjamin Marzinski
2024-11-15 23:22 ` [PATCH 4/6] libmultipath: Add flag to always return device ID when found Benjamin Marzinski
2024-11-15 23:22 ` [PATCH 5/6] libmultipath: check table type in dm_find_map_by_wwid Benjamin Marzinski
2024-11-15 23:22 ` [PATCH 6/6] libmultipath: handle a create corner case for empty devices Benjamin Marzinski
2024-11-18 11:18 ` [PATCH 0/6] multipath-tools: Handle tableless DM devices Martin Wilck
2024-11-18 21:14 ` Benjamin Marzinski [this message]
2024-11-19 12:20 ` Martin Wilck
2024-11-19 16:40 ` Martin Wilck
2024-11-19 19:13 ` Benjamin Marzinski
2024-11-20 8:51 ` Martin Wilck
2024-11-20 19:50 ` Benjamin Marzinski
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=ZzuuUTMJgFPWV16s@redhat.com \
--to=bmarzins@redhat.com \
--cc=christophe.varoqui@opensvc.com \
--cc=dm-devel@lists.linux.dev \
--cc=martin.wilck@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.