| Message ID | 20211118225840.19810-4-mwilck@suse.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | christophe varoqui |
| Headers | show |
| Series | multipathd: uxlsnr overhaul | expand |
On Thu, Nov 18, 2021 at 11:57:55PM +0100, mwilck@suse.com wrote: > From: Martin Wilck <mwilck@suse.com> > > Have struct mutex_lock take an optional wakeup function. > unlock() is renamed to __unlock() in order to prevent it from > being called by mistake. > > This changes offsets in "struct vectors", requiring a major > libmultipath version bump. While the strucure is already changed, > in order to avoid this in the future, move the lock to the end > of "struct vectors". > > Signed-off-by: Martin Wilck <mwilck@suse.com> In libmultipath.version, I would have said that set_wakeup_fn was added in 10.0.0, instead of 9.2.0, which is a version that never actually existed, but I don't think that's going to cause any problems so, Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com> > --- > libmultipath/libmultipath.version | 13 +++++++------ > libmultipath/lock.c | 12 +++++++++++- > libmultipath/lock.h | 6 +++++- > libmultipath/structs_vec.h | 2 +- > 4 files changed, 24 insertions(+), 9 deletions(-) > > diff --git a/libmultipath/libmultipath.version b/libmultipath/libmultipath.version > index c98cf7f..98ec502 100644 > --- a/libmultipath/libmultipath.version > +++ b/libmultipath/libmultipath.version > @@ -31,7 +31,7 @@ > * The new version inherits the previous ones. > */ > > -LIBMULTIPATH_9.0.0 { > +LIBMULTIPATH_10.0.0 { > global: > /* symbols referenced by multipath and multipathd */ > add_foreign; > @@ -284,11 +284,12 @@ global: > /* added in 8.2.0 */ > check_daemon; > > + /* added in 9.1.0 */ > + timespeccmp; > + > + /* added in 9.2.0 */ > + set_wakeup_fn; > + > local: > *; > }; > - > -LIBMULTIPATH_9.1.0 { > -global: > - timespeccmp; > -} LIBMULTIPATH_9.0.0; > diff --git a/libmultipath/lock.c b/libmultipath/lock.c > index 72c70e3..93b48db 100644 > --- a/libmultipath/lock.c > +++ b/libmultipath/lock.c > @@ -3,6 +3,16 @@ > void cleanup_lock (void * data) > { > struct mutex_lock *lock = data; > + wakeup_fn *fn = lock->wakeup; > > - unlock(lock); > + __unlock(lock); > + if (fn) > + fn(); > +} > + > +void set_wakeup_fn(struct mutex_lock *lck, wakeup_fn *fn) > +{ > + lock(lck); > + lck->wakeup = fn; > + __unlock(lck); > } > diff --git a/libmultipath/lock.h b/libmultipath/lock.h > index d99eedb..d7b779e 100644 > --- a/libmultipath/lock.h > +++ b/libmultipath/lock.h > @@ -3,8 +3,11 @@ > > #include <pthread.h> > > +typedef void (wakeup_fn)(void); > + > struct mutex_lock { > pthread_mutex_t mutex; > + wakeup_fn *wakeup; > }; > > static inline void lock(struct mutex_lock *a) > @@ -22,7 +25,7 @@ static inline int timedlock(struct mutex_lock *a, struct timespec *tmo) > return pthread_mutex_timedlock(&a->mutex, tmo); > } > > -static inline void unlock(struct mutex_lock *a) > +static inline void __unlock(struct mutex_lock *a) > { > pthread_mutex_unlock(&a->mutex); > } > @@ -30,5 +33,6 @@ static inline void unlock(struct mutex_lock *a) > #define lock_cleanup_pop(a) pthread_cleanup_pop(1) > > void cleanup_lock (void * data); > +void set_wakeup_fn(struct mutex_lock *lock, wakeup_fn *fn); > > #endif /* _LOCK_H */ > diff --git a/libmultipath/structs_vec.h b/libmultipath/structs_vec.h > index 29ede45..2a0cbd1 100644 > --- a/libmultipath/structs_vec.h > +++ b/libmultipath/structs_vec.h > @@ -6,9 +6,9 @@ > #include "lock.h" > > struct vectors { > - struct mutex_lock lock; /* defined in lock.h */ > vector pathvec; > vector mpvec; > + struct mutex_lock lock; /* defined in lock.h */ > }; > > void __set_no_path_retry(struct multipath *mpp, bool check_features); > -- > 2.33.1 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, 2021-11-24 at 14:41 -0600, Benjamin Marzinski wrote: > On Thu, Nov 18, 2021 at 11:57:55PM +0100, mwilck@suse.com wrote: > > From: Martin Wilck <mwilck@suse.com> > > > > Have struct mutex_lock take an optional wakeup function. > > unlock() is renamed to __unlock() in order to prevent it from > > being called by mistake. > > > > This changes offsets in "struct vectors", requiring a major > > libmultipath version bump. While the strucure is already changed, > > in order to avoid this in the future, move the lock to the end > > of "struct vectors". > > > > Signed-off-by: Martin Wilck <mwilck@suse.com> > > In libmultipath.version, I would have said that set_wakeup_fn was > added > in 10.0.0, instead of 9.2.0, which is a version that never actually > existed, but I don't think that's going to cause any problems so, > > Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com> We should consider whether we want bump the version numbers only when we submit to Christophe, or maybe once per major patch series that touches the ABI. This is something that I could Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, Nov 24, 2021 at 10:20:53PM +0100, Martin Wilck wrote: > On Wed, 2021-11-24 at 14:41 -0600, Benjamin Marzinski wrote: > > On Thu, Nov 18, 2021 at 11:57:55PM +0100, mwilck@suse.com wrote: > > > From: Martin Wilck <mwilck@suse.com> > > > > > > Have struct mutex_lock take an optional wakeup function. > > > unlock() is renamed to __unlock() in order to prevent it from > > > being called by mistake. > > > > > > This changes offsets in "struct vectors", requiring a major > > > libmultipath version bump. While the strucure is already changed, > > > in order to avoid this in the future, move the lock to the end > > > of "struct vectors". > > > > > > Signed-off-by: Martin Wilck <mwilck@suse.com> > > > > In libmultipath.version, I would have said that set_wakeup_fn was > > added > > in 10.0.0, instead of 9.2.0, which is a version that never actually > > existed, but I don't think that's going to cause any problems so, > > > > Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com> > > We should consider whether we want bump the version numbers only when > we submit to Christophe, or maybe once per major patch series that > touches the ABI. This is something that I could I suppose that we could just bump the version the first time after a push to Christophe that an ABI change is made, and then just make all the symbol changes under that version until Christophe makes another release. If the first change only caused a minor version bump, and a later change needed a major bump we could have two version bumps in a release, but I don't think we're getting any benefit from making more. But once per patchset works fine for me too. -Ben > > Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Mon, 2021-11-29 at 13:27 -0600, Benjamin Marzinski wrote: > On Wed, Nov 24, 2021 at 10:20:53PM +0100, Martin Wilck wrote: > > On Wed, 2021-11-24 at 14:41 -0600, Benjamin Marzinski wrote: > > > On Thu, Nov 18, 2021 at 11:57:55PM +0100, mwilck@suse.com wrote: > > > > From: Martin Wilck <mwilck@suse.com> > > > > > > > > Have struct mutex_lock take an optional wakeup function. > > > > unlock() is renamed to __unlock() in order to prevent it from > > > > being called by mistake. > > > > > > > > This changes offsets in "struct vectors", requiring a major > > > > libmultipath version bump. While the strucure is already > > > > changed, > > > > in order to avoid this in the future, move the lock to the end > > > > of "struct vectors". > > > > > > > > Signed-off-by: Martin Wilck <mwilck@suse.com> > > > > > > In libmultipath.version, I would have said that set_wakeup_fn was > > > added > > > in 10.0.0, instead of 9.2.0, which is a version that never > > > actually > > > existed, but I don't think that's going to cause any problems so, > > > > > > Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com> > > > > We should consider whether we want bump the version numbers only > > when > > we submit to Christophe, or maybe once per major patch series that > > touches the ABI. This is something that I could > > I suppose that we could just bump the version the first time after a > push to Christophe that an ABI change is made, and then just make all > the symbol changes under that version until Christophe makes another > release. If the first change only caused a minor version bump, and a > later change needed a major bump we could have two version bumps in a > release, but I don't think we're getting any benefit from making > more. > But once per patchset works fine for me too. I agree. Also, I realize that we've bumped the library version too often in the past. If we add a function, we don't need to bump. Because a program that needs the added function will require e.g. foo@LIBMULTIPATH_10.0.0, and this will fail for a library that doesn't export foo (which is what we want). Likewise for function deletion - a program that calls the deleted function will fail to link with the updated library. OTOH, programs that use this version of the ABI *without* using the functions which are added or removed are unaffected by the addition / removal. The only case in which the ABI version must be bumped is when we have changed functions or data structures. Furthermore, I believe now that the habit (which I introduced) to list added functions at the end of the .version files, with comments indicating when they were added, is useless. We should rather keep the .version file ordered alphabetically. Regards Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Mon, Nov 29, 2021 at 09:52:49PM +0100, Martin Wilck wrote: > On Mon, 2021-11-29 at 13:27 -0600, Benjamin Marzinski wrote: > > On Wed, Nov 24, 2021 at 10:20:53PM +0100, Martin Wilck wrote: > > > On Wed, 2021-11-24 at 14:41 -0600, Benjamin Marzinski wrote: > > > > On Thu, Nov 18, 2021 at 11:57:55PM +0100, mwilck@suse.com wrote: > > > > > From: Martin Wilck <mwilck@suse.com> > > > > > > > > > > Have struct mutex_lock take an optional wakeup function. > > > > > unlock() is renamed to __unlock() in order to prevent it from > > > > > being called by mistake. > > > > > > > > > > This changes offsets in "struct vectors", requiring a major > > > > > libmultipath version bump. While the strucure is already > > > > > changed, > > > > > in order to avoid this in the future, move the lock to the end > > > > > of "struct vectors". > > > > > > > > > > Signed-off-by: Martin Wilck <mwilck@suse.com> > > > > > > > > In libmultipath.version, I would have said that set_wakeup_fn was > > > > added > > > > in 10.0.0, instead of 9.2.0, which is a version that never > > > > actually > > > > existed, but I don't think that's going to cause any problems so, > > > > > > > > Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com> > > > > > > We should consider whether we want bump the version numbers only > > > when > > > we submit to Christophe, or maybe once per major patch series that > > > touches the ABI. This is something that I could > > > > I suppose that we could just bump the version the first time after a > > push to Christophe that an ABI change is made, and then just make all > > the symbol changes under that version until Christophe makes another > > release. If the first change only caused a minor version bump, and a > > later change needed a major bump we could have two version bumps in a > > release, but I don't think we're getting any benefit from making > > more. > > But once per patchset works fine for me too. > > I agree. Also, I realize that we've bumped the library version too > often in the past. If we add a function, we don't need to bump. Because > a program that needs the added function will require e.g. > foo@LIBMULTIPATH_10.0.0, and this will fail for a library that doesn't > export foo (which is what we want). Likewise for function deletion - a > program that calls the deleted function will fail to link with the > updated library. OTOH, programs that use this version of the ABI > *without* using the functions which are added or removed are unaffected > by the addition / removal. > > The only case in which the ABI version must be bumped is when we have > changed functions or data structures. > > Furthermore, I believe now that the habit (which I introduced) to list > added functions at the end of the .version files, with comments > indicating when they were added, is useless. We should rather keep the > .version file ordered alphabetically. So we not use the minor version anymore? -Ben > > Regards > Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, 2021-11-30 at 10:52 -0600, Benjamin Marzinski wrote: > On Mon, Nov 29, 2021 at 09:52:49PM +0100, Martin Wilck wrote: > > I agree. Also, I realize that we've bumped the library version too > > often in the past. If we add a function, we don't need to bump. > > Because > > a program that needs the added function will require e.g. > > foo@LIBMULTIPATH_10.0.0, and this will fail for a library that > > doesn't > > export foo (which is what we want). Likewise for function deletion > > - a > > program that calls the deleted function will fail to link with the > > updated library. OTOH, programs that use this version of the ABI > > *without* using the functions which are added or removed are > > unaffected > > by the addition / removal. > > > > The only case in which the ABI version must be bumped is when we > > have > > changed functions or data structures. > > > > Furthermore, I believe now that the habit (which I introduced) to > > list > > added functions at the end of the .version files, with comments > > indicating when they were added, is useless. We should rather keep > > the > > .version file ordered alphabetically. > > So we not use the minor version anymore? Perhaps we'll encounter another use case for it, or we find a flaw in my reasoning above. I wouldn't remove the digit. We could e.g. bump the minor version in an official release if there are only minor ABI changes wrt the previous official release. Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, 2021-11-30 at 21:28 +0100, Martin Wilck wrote: > On Tue, 2021-11-30 at 10:52 -0600, Benjamin Marzinski wrote: > > On Mon, Nov 29, 2021 at 09:52:49PM +0100, Martin Wilck wrote: > > > I agree. Also, I realize that we've bumped the library version > > > too > > > often in the past. If we add a function, we don't need to bump. > > > Because > > > a program that needs the added function will require e.g. > > > foo@LIBMULTIPATH_10.0.0, and this will fail for a library that > > > doesn't > > > export foo (which is what we want). Likewise for function > > > deletion > > > - a > > > program that calls the deleted function will fail to link with > > > the > > > updated library. OTOH, programs that use this version of the ABI > > > *without* using the functions which are added or removed are > > > unaffected > > > by the addition / removal. > > > > > > The only case in which the ABI version must be bumped is when we > > > have > > > changed functions or data structures. > > > > > > Furthermore, I believe now that the habit (which I introduced) to > > > list > > > added functions at the end of the .version files, with comments > > > indicating when they were added, is useless. We should rather > > > keep > > > the > > > .version file ordered alphabetically. > > > > So we not use the minor version anymore? > > Perhaps we'll encounter another use case for it, or we find a flaw in > my reasoning above. I wouldn't remove the digit. And here's the flaw: While my argument above is valid for ld.so, it's not for package management tools like rpm. Here on openSUSE, we got rpm Requires like "libmultipath.so.0(LIBMULTIPATH_13.0.0)(64bit)". As distributors, we prefer incompatibilities to be detected at installation time rather than at runtime. So, we do need the minor version bumps. Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, Dec 01, 2021 at 01:06:45PM +0100, Martin Wilck wrote: > On Tue, 2021-11-30 at 21:28 +0100, Martin Wilck wrote: > > On Tue, 2021-11-30 at 10:52 -0600, Benjamin Marzinski wrote: > > > On Mon, Nov 29, 2021 at 09:52:49PM +0100, Martin Wilck wrote: > > > > I agree. Also, I realize that we've bumped the library version > > > > too > > > > often in the past. If we add a function, we don't need to bump. > > > > Because > > > > a program that needs the added function will require e.g. > > > > foo@LIBMULTIPATH_10.0.0, and this will fail for a library that > > > > doesn't > > > > export foo (which is what we want). Likewise for function > > > > deletion > > > > - a > > > > program that calls the deleted function will fail to link with > > > > the > > > > updated library. OTOH, programs that use this version of the ABI > > > > *without* using the functions which are added or removed are > > > > unaffected > > > > by the addition / removal. > > > > > > > > The only case in which the ABI version must be bumped is when we > > > > have > > > > changed functions or data structures. > > > > > > > > Furthermore, I believe now that the habit (which I introduced) to > > > > list > > > > added functions at the end of the .version files, with comments > > > > indicating when they were added, is useless. We should rather > > > > keep > > > > the > > > > .version file ordered alphabetically. > > > > > > So we not use the minor version anymore? > > > > Perhaps we'll encounter another use case for it, or we find a flaw in > > my reasoning above. I wouldn't remove the digit. > > And here's the flaw: While my argument above is valid for ld.so, it's > not for package management tools like rpm. Here on openSUSE, we got rpm > Requires like "libmultipath.so.0(LIBMULTIPATH_13.0.0)(64bit)". As > distributors, we prefer incompatibilities to be detected at > installation time rather than at runtime. So, we do need the minor > version bumps. So where does this leave us. Are we bumping versions once per merge to Christophe's offical branch, and if distributions put out multiple releases between these, they are responsible for any version bumps that they need. Or are we bumping versions once per patchset if needed? -Ben > > Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, 2021-12-14 at 17:25 -0600, Benjamin Marzinski wrote: > On Wed, Dec 01, 2021 at 01:06:45PM +0100, Martin Wilck wrote: > > On Tue, 2021-11-30 at 21:28 +0100, Martin Wilck wrote: > > > > > > Perhaps we'll encounter another use case for it, or we find a > > > flaw in > > > my reasoning above. I wouldn't remove the digit. > > > > And here's the flaw: While my argument above is valid for ld.so, > > it's > > not for package management tools like rpm. Here on openSUSE, we got > > rpm > > Requires like "libmultipath.so.0(LIBMULTIPATH_13.0.0)(64bit)". As > > distributors, we prefer incompatibilities to be detected at > > installation time rather than at runtime. So, we do need the minor > > version bumps. > > So where does this leave us. Are we bumping versions once per merge > to > Christophe's offical branch, and if distributions put out multiple > releases between these, they are responsible for any version bumps > that > they need. Or are we bumping versions once per patchset if needed? I just wanted to say that my previous argument that addition or removal of symbols can be ignored was wrong, and that we should keep the treatment of minor versions as originally designed. I am fine with us not touching the .version files while we work on new patch sets, and leaving it to the person perparing a PR for Christope (likely myself) to fix it up when a patch series is finished. In practice, it'll probably result in just a major version bump per submission to Christophe, but that isn't cast in stone (if we submit a smaller set of patches, it might be just a minor bump, or none at all). Distros are free to modify the last digit as they please. Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
Hi Ben, On Wed, 2021-12-15 at 08:33 +0100, Martin Wilck wrote: > > I just wanted to say that my previous argument that addition or > removal > of symbols can be ignored was wrong, and that we should keep the > treatment of minor versions as originally designed. I am fine with us > not touching the .version files while we work on new patch sets, and > leaving it to the person perparing a PR for Christope (likely myself) > to fix it up when a patch series is finished. In practice, it'll > probably result in just a major version bump per submission to > Christophe, but that isn't cast in stone (if we submit a smaller set > of > patches, it might be just a minor bump, or none at all). > > Distros are free to modify the last digit as they please. Here's what I think I should do: I'll keep one patch on top of the "queue" branch that includes the necessary ABI bumps. I'll fix this patch up as commits are added to "queue". This means the queue branch (more precisely, the topmost commit) will need to be rebased. It won't be a problem as this commit will only touch the .version files, nothing else. This way builds from "queue" will be "safe" against library incompatibilities wrt the official release, and yet we won't need to bump the major version multiple times for a single submission to Christophe. Submissions to Christophe will come with either no bump, or a single-step minor bump, or a single-step major bump. Does this make sense? Regards Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, Dec 15, 2021 at 10:01:34PM +0100, Martin Wilck wrote: > Hi Ben, > > On Wed, 2021-12-15 at 08:33 +0100, Martin Wilck wrote: > > > > I just wanted to say that my previous argument that addition or > > removal > > of symbols can be ignored was wrong, and that we should keep the > > treatment of minor versions as originally designed. I am fine with us > > not touching the .version files while we work on new patch sets, and > > leaving it to the person perparing a PR for Christope (likely myself) > > to fix it up when a patch series is finished. In practice, it'll > > probably result in just a major version bump per submission to > > Christophe, but that isn't cast in stone (if we submit a smaller set > > of > > patches, it might be just a minor bump, or none at all). > > > > Distros are free to modify the last digit as they please. > > Here's what I think I should do: I'll keep one patch on top of the > "queue" branch that includes the necessary ABI bumps. I'll fix this > patch up as commits are added to "queue". This means the queue branch > (more precisely, the topmost commit) will need to be rebased. It won't > be a problem as this commit will only touch the .version files, nothing > else. This way builds from "queue" will be "safe" against library > incompatibilities wrt the official release, and yet we won't need to > bump the major version multiple times for a single submission to > Christophe. Submissions to Christophe will come with either no bump, or > a single-step minor bump, or a single-step major bump. > > Does this make sense? > Sure. I'm fine with that. -Ben > Regards > Martin -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
diff --git a/libmultipath/libmultipath.version b/libmultipath/libmultipath.version index c98cf7f..98ec502 100644 --- a/libmultipath/libmultipath.version +++ b/libmultipath/libmultipath.version @@ -31,7 +31,7 @@ * The new version inherits the previous ones. */ -LIBMULTIPATH_9.0.0 { +LIBMULTIPATH_10.0.0 { global: /* symbols referenced by multipath and multipathd */ add_foreign; @@ -284,11 +284,12 @@ global: /* added in 8.2.0 */ check_daemon; + /* added in 9.1.0 */ + timespeccmp; + + /* added in 9.2.0 */ + set_wakeup_fn; + local: *; }; - -LIBMULTIPATH_9.1.0 { -global: - timespeccmp; -} LIBMULTIPATH_9.0.0; diff --git a/libmultipath/lock.c b/libmultipath/lock.c index 72c70e3..93b48db 100644 --- a/libmultipath/lock.c +++ b/libmultipath/lock.c @@ -3,6 +3,16 @@ void cleanup_lock (void * data) { struct mutex_lock *lock = data; + wakeup_fn *fn = lock->wakeup; - unlock(lock); + __unlock(lock); + if (fn) + fn(); +} + +void set_wakeup_fn(struct mutex_lock *lck, wakeup_fn *fn) +{ + lock(lck); + lck->wakeup = fn; + __unlock(lck); } diff --git a/libmultipath/lock.h b/libmultipath/lock.h index d99eedb..d7b779e 100644 --- a/libmultipath/lock.h +++ b/libmultipath/lock.h @@ -3,8 +3,11 @@ #include <pthread.h> +typedef void (wakeup_fn)(void); + struct mutex_lock { pthread_mutex_t mutex; + wakeup_fn *wakeup; }; static inline void lock(struct mutex_lock *a) @@ -22,7 +25,7 @@ static inline int timedlock(struct mutex_lock *a, struct timespec *tmo) return pthread_mutex_timedlock(&a->mutex, tmo); } -static inline void unlock(struct mutex_lock *a) +static inline void __unlock(struct mutex_lock *a) { pthread_mutex_unlock(&a->mutex); } @@ -30,5 +33,6 @@ static inline void unlock(struct mutex_lock *a) #define lock_cleanup_pop(a) pthread_cleanup_pop(1) void cleanup_lock (void * data); +void set_wakeup_fn(struct mutex_lock *lock, wakeup_fn *fn); #endif /* _LOCK_H */ diff --git a/libmultipath/structs_vec.h b/libmultipath/structs_vec.h index 29ede45..2a0cbd1 100644 --- a/libmultipath/structs_vec.h +++ b/libmultipath/structs_vec.h @@ -6,9 +6,9 @@ #include "lock.h" struct vectors { - struct mutex_lock lock; /* defined in lock.h */ vector pathvec; vector mpvec; + struct mutex_lock lock; /* defined in lock.h */ }; void __set_no_path_retry(struct multipath *mpp, bool check_features);