Move code closer to usage.
Signed-off-by: John Ferlan <jferlan@redhat.com>
---
src/conf/virsecretobj.c | 62 ++++++++++++++++++++++++-------------------------
src/conf/virsecretobj.h | 14 +++++------
2 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/src/conf/virsecretobj.c b/src/conf/virsecretobj.c
index 413955d..998f815 100644
--- a/src/conf/virsecretobj.c
+++ b/src/conf/virsecretobj.c
@@ -483,6 +483,37 @@ virSecretObjListNumOfSecrets(virSecretObjListPtr secrets,
}
+int
+virSecretObjListGetUUIDs(virSecretObjListPtr secrets,
+ char **uuids,
+ int nuuids,
+ virSecretObjListACLFilter filter,
+ virConnectPtr conn)
+{
+ int ret = -1;
+
+ struct virSecretObjListGetHelperData data = {
+ .conn = conn, .filter = filter, .got = 0,
+ .uuids = uuids, .nuuids = nuuids, .error = false };
+
+ virObjectLock(secrets);
+ virHashForEach(secrets->objs, virSecretObjListGetHelper, &data);
+ virObjectUnlock(secrets);
+
+ if (data.error)
+ goto cleanup;
+
+ ret = data.got;
+
+ cleanup:
+ if (ret < 0) {
+ while (data.got)
+ VIR_FREE(data.uuids[--data.got]);
+ }
+ return ret;
+}
+
+
#define MATCH(FLAG) (flags & (FLAG))
static bool
virSecretObjMatchFlags(virSecretObjPtr obj,
@@ -605,37 +636,6 @@ virSecretObjListExport(virConnectPtr conn,
int
-virSecretObjListGetUUIDs(virSecretObjListPtr secrets,
- char **uuids,
- int nuuids,
- virSecretObjListACLFilter filter,
- virConnectPtr conn)
-{
- int ret = -1;
-
- struct virSecretObjListGetHelperData data = {
- .conn = conn, .filter = filter, .got = 0,
- .uuids = uuids, .nuuids = nuuids, .error = false };
-
- virObjectLock(secrets);
- virHashForEach(secrets->objs, virSecretObjListGetHelper, &data);
- virObjectUnlock(secrets);
-
- if (data.error)
- goto cleanup;
-
- ret = data.got;
-
- cleanup:
- if (ret < 0) {
- while (data.got)
- VIR_FREE(data.uuids[--data.got]);
- }
- return ret;
-}
-
-
-int
virSecretObjDeleteConfig(virSecretObjPtr obj)
{
virSecretDefPtr def = obj->def;
diff --git a/src/conf/virsecretobj.h b/src/conf/virsecretobj.h
index 8038faa..82915d0 100644
--- a/src/conf/virsecretobj.h
+++ b/src/conf/virsecretobj.h
@@ -67,13 +67,6 @@ virSecretObjListNumOfSecrets(virSecretObjListPtr secrets,
virConnectPtr conn);
int
-virSecretObjListExport(virConnectPtr conn,
- virSecretObjListPtr secretobjs,
- virSecretPtr **secrets,
- virSecretObjListACLFilter filter,
- unsigned int flags);
-
-int
virSecretObjListGetUUIDs(virSecretObjListPtr secrets,
char **uuids,
int nuuids,
@@ -81,6 +74,13 @@ virSecretObjListGetUUIDs(virSecretObjListPtr secrets,
virConnectPtr conn);
int
+virSecretObjListExport(virConnectPtr conn,
+ virSecretObjListPtr secretobjs,
+ virSecretPtr **secrets,
+ virSecretObjListACLFilter filter,
+ unsigned int flags);
+
+int
virSecretObjDeleteConfig(virSecretObjPtr obj);
void
--
2.9.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Mon, Apr 24, 2017 at 02:00:16PM -0400, John Ferlan wrote: > Move code closer to usage. NACK, the function is exported so the usage is not only inside this file. In addition it adds an extra step while tracing the history of the code. Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 04/25/2017 04:39 AM, Pavel Hrdina wrote: > On Mon, Apr 24, 2017 at 02:00:16PM -0400, John Ferlan wrote: >> Move code closer to usage. > > NACK, the function is exported so the usage is not only inside this file. > In addition it adds an extra step while tracing the history of the code. > > Pavel > While I don't agree, but I can drop this - again, in patches not yet posted it's a lot easier to read the code with the GetUUIDs closer to what GetHelper (or what it becomes by patch9). John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Apr 25, 2017 at 08:00:26AM -0400, John Ferlan wrote: > > > On 04/25/2017 04:39 AM, Pavel Hrdina wrote: > > On Mon, Apr 24, 2017 at 02:00:16PM -0400, John Ferlan wrote: > >> Move code closer to usage. > > > > NACK, the function is exported so the usage is not only inside this file. > > In addition it adds an extra step while tracing the history of the code. > > > > Pavel > > > > While I don't agree, but I can drop this - again, in patches not yet > posted it's a lot easier to read the code with the GetUUIDs closer to > what GetHelper (or what it becomes by patch9). I thing that it's OK to have both *Callback functions next to each other followed by the virSecretObjListNumOfSecrets and virSecretObjListGetUUIDs next to each other. Pavel > > > John > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 04/25/2017 08:42 AM, Pavel Hrdina wrote: > On Tue, Apr 25, 2017 at 08:00:26AM -0400, John Ferlan wrote: >> >> >> On 04/25/2017 04:39 AM, Pavel Hrdina wrote: >>> On Mon, Apr 24, 2017 at 02:00:16PM -0400, John Ferlan wrote: >>>> Move code closer to usage. >>> >>> NACK, the function is exported so the usage is not only inside this file. >>> In addition it adds an extra step while tracing the history of the code. >>> >>> Pavel >>> >> >> While I don't agree, but I can drop this - again, in patches not yet >> posted it's a lot easier to read the code with the GetUUIDs closer to >> what GetHelper (or what it becomes by patch9). > > I thing that it's OK to have both *Callback functions next to each other > followed by the virSecretObjListNumOfSecrets and virSecretObjListGetUUIDs > next to each other. > Exactly, but you NACK'd the code motion. Now I'm confused. BTW: After this patch the order is: virSecretObjListGetHelper <= Used for both NumOf and GetUUIDs virSecretObjListNumOfSecrets <= API virSecretObjListGetUUIDs <= API virSecretObjMatchFlags <= Used by ListPopulate virSecretObjListPopulate <= Used by ListExport virSecretObjListExport <== API John > Pavel > >> >> >> John >> >> -- >> libvir-list mailing list >> libvir-list@redhat.com >> https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Apr 25, 2017 at 09:46:50AM -0400, John Ferlan wrote: > > > On 04/25/2017 08:42 AM, Pavel Hrdina wrote: > > On Tue, Apr 25, 2017 at 08:00:26AM -0400, John Ferlan wrote: > >> > >> > >> On 04/25/2017 04:39 AM, Pavel Hrdina wrote: > >>> On Mon, Apr 24, 2017 at 02:00:16PM -0400, John Ferlan wrote: > >>>> Move code closer to usage. > >>> > >>> NACK, the function is exported so the usage is not only inside this file. > >>> In addition it adds an extra step while tracing the history of the code. > >>> > >>> Pavel > >>> > >> > >> While I don't agree, but I can drop this - again, in patches not yet > >> posted it's a lot easier to read the code with the GetUUIDs closer to > >> what GetHelper (or what it becomes by patch9). > > > > I thing that it's OK to have both *Callback functions next to each other > > followed by the virSecretObjListNumOfSecrets and virSecretObjListGetUUIDs > > next to each other. > > > > Exactly, but you NACK'd the code motion. Now I'm confused. What I meant is that in this case the order of functions doesn't matter so the code movement is pointless, the only benefit is that it may look better if you scrolling throughout the code. I don't want create a precedent that moving function just for cosmetic reasons is a valid reason :). Pavel > BTW: After this patch the order is: > > virSecretObjListGetHelper <= Used for both NumOf and GetUUIDs > virSecretObjListNumOfSecrets <= API > virSecretObjListGetUUIDs <= API > virSecretObjMatchFlags <= Used by ListPopulate > virSecretObjListPopulate <= Used by ListExport > virSecretObjListExport <== API > > John > > > Pavel > > > >> > >> > >> John > >> > >> -- > >> libvir-list mailing list > >> libvir-list@redhat.com > >> https://www.redhat.com/mailman/listinfo/libvir-list > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 04/25/2017 09:56 AM, Pavel Hrdina wrote: > On Tue, Apr 25, 2017 at 09:46:50AM -0400, John Ferlan wrote: >> >> >> On 04/25/2017 08:42 AM, Pavel Hrdina wrote: >>> On Tue, Apr 25, 2017 at 08:00:26AM -0400, John Ferlan wrote: >>>> >>>> >>>> On 04/25/2017 04:39 AM, Pavel Hrdina wrote: >>>>> On Mon, Apr 24, 2017 at 02:00:16PM -0400, John Ferlan wrote: >>>>>> Move code closer to usage. >>>>> >>>>> NACK, the function is exported so the usage is not only inside this file. >>>>> In addition it adds an extra step while tracing the history of the code. >>>>> >>>>> Pavel >>>>> >>>> >>>> While I don't agree, but I can drop this - again, in patches not yet >>>> posted it's a lot easier to read the code with the GetUUIDs closer to >>>> what GetHelper (or what it becomes by patch9). >>> >>> I thing that it's OK to have both *Callback functions next to each other >>> followed by the virSecretObjListNumOfSecrets and virSecretObjListGetUUIDs >>> next to each other. >>> >> >> Exactly, but you NACK'd the code motion. Now I'm confused. > > What I meant is that in this case the order of functions doesn't matter > so the code movement is pointless, the only benefit is that it may look > better if you scrolling throughout the code. I don't want create a > precedent that moving function just for cosmetic reasons is a valid > reason :). > That precedent ship sailed long ago. Moving code for cosmetic reasons and reordering code has been done numerous times. Many times to make it easier to see differences in subsequent patches. I can drop this patch, but once I get to patch 9 I'd keep the Callback helper next to the external API. So it's either pointless now or then. John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2026 Red Hat, Inc.