On Thu, Jul 14, 2022 at 4:34 AM Peter Smith <smithpb2...@gmail.com> wrote: > > On Wed, Jul 13, 2022 at 7:55 PM vignesh C <vignes...@gmail.com> wrote: > > > > On Wed, Jul 13, 2022 at 1:13 PM Michael Paquier <mich...@paquier.xyz> wrote: > > > > > > On Wed, Jul 13, 2022 at 12:22:06PM +0530, vignesh C wrote: > > > > Most of the code is common between GetSubscriptionRelations and > > > > GetSubscriptionNotReadyRelations. Added a parameter to > > > > GetSubscriptionRelations which could provide the same functionality as > > > > the existing GetSubscriptionRelations and > > > > GetSubscriptionNotReadyRelations. Attached patch has the changes for > > > > the same. Thoughts? > > > > > > Right. Using all_rels to mean that we'd filter relations that are not > > > ready is a bit confusing, though. Perhaps this could use a bitmask as > > > argument. > > > > The attached v2 patch has the modified version which includes the > > changes to make the argument as bitmask. > > > > By using a bitmask I think there is an implication that the flags can > be combined... > > Perhaps it is not a problem today, but later you may want more flags. e.g. > #define SUBSCRIPTION_REL_STATE_READY 0x02 /* READY relations */ > > then the bitmask idea falls apart because IIUC you have no intentions > to permit things like: > (SUBSCRIPTION_REL_STATE_NOT_READY | SUBSCRIPTION_REL_STATE_READY) >
I think this will be an invalid combination if caller ever used it. However, one might need to use a combination like (SUBSCRIPTION_REL_STATE_READY | SUBSCRIPTION_REL_STATE_DONE). For such cases, I feel the bitmask idea will be better. -- With Regards, Amit Kapila.
