Message ID | 1478864601-3259-3-git-send-email-yauheni.kaliuta@redhat.com (mailing list archive) |
---|---|
State | Changes Requested |
Headers | show |
On Fri, Nov 11, 2016 at 3:43 AM, Yauheni Kaliuta <yauheni.kaliuta@redhat.com> wrote: > The library uses list functions to create lists internally and > provides to the clients immutable lists and only functions to > traverse them. > > It may be useful to create own lists in the kmod utilities, so > export functions for lists creation as well (as it's done for > arrays). The following functions affected (needed for the > following depmod modifications): > > kmod_list_append() > kmod_list_remove() > kmod_list_remove_data() > > The patch also adds kmod_list_data() accessor to keep the > struct kmod_list opaque. I don't see a use for these functions outside of the tools we provide. We don't need to export them (to external users) in order to use for our tools. You can just make the tools include libkmod-internal.h and use that. In fact since you didn't update the .sym file what will happen is that external users will see a function in the header but won't be able to use it since it will not be part of the .so. Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Lucas! >>>>> On Mon, 13 Feb 2017 00:05:07 -0800, Lucas De Marchi wrote: > On Fri, Nov 11, 2016 at 3:43 AM, Yauheni Kaliuta > <yauheni.kaliuta@redhat.com> wrote: >> The library uses list functions to create lists internally and >> provides to the clients immutable lists and only functions to >> traverse them. >> >> It may be useful to create own lists in the kmod utilities, so >> export functions for lists creation as well (as it's done for >> arrays). The following functions affected (needed for the >> following depmod modifications): >> >> kmod_list_append() >> kmod_list_remove() >> kmod_list_remove_data() >> >> The patch also adds kmod_list_data() accessor to keep the >> struct kmod_list opaque. > I don't see a use for these functions outside of the tools we provide. > We don't need to export them (to external users) in order to use for > our tools. You can just make the tools include libkmod-internal.h and > use that. > In fact since you didn't update the .sym file what will happen is that > external users will see a function in the header but won't be able to > use it since it will not be part of the .so. Hmm, log macros redefined in this case: CC tools/depmod.o In file included from tools/kmod.h:42:0, from tools/depmod.c:42: tools/log.h:31:0: warning: "ERR" redefined #define ERR(...) log_printf(LOG_ERR, __VA_ARGS__) In file included from tools/depmod.c:40:0: ./libkmod/libkmod-internal.h:29:0: note: this is the location of the previous definition # define ERR(ctx, arg...) kmod_log_cond(ctx, LOG_ERR, ## arg) Would include libkmod-internal.h, then undef then, then include kmod.h be acceptable?
On Mon, Feb 20, 2017 at 6:22 AM, Yauheni Kaliuta <yauheni.kaliuta@redhat.com> wrote: > Hi, Lucas! > >>>>>> On Mon, 13 Feb 2017 00:05:07 -0800, Lucas De Marchi wrote: > > > On Fri, Nov 11, 2016 at 3:43 AM, Yauheni Kaliuta > > <yauheni.kaliuta@redhat.com> wrote: > >> The library uses list functions to create lists internally and > >> provides to the clients immutable lists and only functions to > >> traverse them. > >> > >> It may be useful to create own lists in the kmod utilities, so > >> export functions for lists creation as well (as it's done for > >> arrays). The following functions affected (needed for the > >> following depmod modifications): > >> > >> kmod_list_append() > >> kmod_list_remove() > >> kmod_list_remove_data() > >> > >> The patch also adds kmod_list_data() accessor to keep the > >> struct kmod_list opaque. > > > I don't see a use for these functions outside of the tools we provide. > > We don't need to export them (to external users) in order to use for > > our tools. You can just make the tools include libkmod-internal.h and > > use that. > > > In fact since you didn't update the .sym file what will happen is that > > external users will see a function in the header but won't be able to > > use it since it will not be part of the .so. > > Hmm, log macros redefined in this case: > > CC tools/depmod.o > In file included from tools/kmod.h:42:0, > from tools/depmod.c:42: > tools/log.h:31:0: warning: "ERR" redefined > #define ERR(...) log_printf(LOG_ERR, __VA_ARGS__) > > In file included from tools/depmod.c:40:0: > ./libkmod/libkmod-internal.h:29:0: note: this is the location of the previous definition > # define ERR(ctx, arg...) kmod_log_cond(ctx, LOG_ERR, ## arg) > > > Would include libkmod-internal.h, then undef then, then include kmod.h be > acceptable? This is the approach taken by testsuite. So, yes, it's fine for now. Since we always include with order system headers, lib headers, local headers, we could even make the undef on tools/log.h, so inside the tools we use our local logging macros. Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
V3->V2: - depmod.c: undefine ERR and DBG macros, included by libkmod-internal.h V1->V2: - use libkmod-internal.h and access list value directly; - initially create reverse array with 3 elements; - use memcpy() instead of strcpy() in depmod_report_one_cycle(); - replace "because" with "since" in comment about single branch. Yauheni Kaliuta (2): testsuite: depmod: check netsted loops reporting depmod: handle nested loops Makefile.am | 4 + testsuite/module-playground/Makefile | 7 + testsuite/module-playground/cache/mod-loop-h.ko | Bin 0 -> 197808 bytes testsuite/module-playground/cache/mod-loop-i.ko | Bin 0 -> 197808 bytes testsuite/module-playground/cache/mod-loop-j.ko | Bin 0 -> 197968 bytes testsuite/module-playground/cache/mod-loop-k.ko | Bin 0 -> 197808 bytes testsuite/module-playground/mod-loop-h.c | 25 ++ testsuite/module-playground/mod-loop-i.c | 25 ++ testsuite/module-playground/mod-loop-j.c | 26 ++ testsuite/module-playground/mod-loop-k.c | 25 ++ testsuite/module-playground/mod-loop.h | 4 + testsuite/populate-modules.sh | 4 + .../test-depmod/detect-loop/correct.txt | 6 +- tools/depmod.c | 295 +++++++++++++++------ 14 files changed, 335 insertions(+), 86 deletions(-) create mode 100644 testsuite/module-playground/cache/mod-loop-h.ko create mode 100644 testsuite/module-playground/cache/mod-loop-i.ko create mode 100644 testsuite/module-playground/cache/mod-loop-j.ko create mode 100644 testsuite/module-playground/cache/mod-loop-k.ko create mode 100644 testsuite/module-playground/mod-loop-h.c create mode 100644 testsuite/module-playground/mod-loop-i.c create mode 100644 testsuite/module-playground/mod-loop-j.c create mode 100644 testsuite/module-playground/mod-loop-k.c
diff --git a/libkmod/libkmod-internal.h b/libkmod/libkmod-internal.h index 4d9db6bc7845..fd1eaed6f556 100644 --- a/libkmod/libkmod-internal.h +++ b/libkmod/libkmod-internal.h @@ -59,11 +59,7 @@ struct kmod_list { void *data; }; -struct kmod_list *kmod_list_append(struct kmod_list *list, const void *data) _must_check_ __attribute__((nonnull(2))); struct kmod_list *kmod_list_prepend(struct kmod_list *list, const void *data) _must_check_ __attribute__((nonnull(2))); -struct kmod_list *kmod_list_remove(struct kmod_list *list) _must_check_; -struct kmod_list *kmod_list_remove_data(struct kmod_list *list, - const void *data) _must_check_ __attribute__((nonnull(2))); struct kmod_list *kmod_list_remove_n_latest(struct kmod_list *list, unsigned int n) _must_check_; struct kmod_list *kmod_list_insert_after(struct kmod_list *list, const void *data) __attribute__((nonnull(2))); diff --git a/libkmod/libkmod-list.c b/libkmod/libkmod-list.c index 7623693ac12e..8dd445e9829a 100644 --- a/libkmod/libkmod-list.c +++ b/libkmod/libkmod-list.c @@ -186,7 +186,15 @@ struct kmod_list *kmod_list_prepend(struct kmod_list *list, const void *data) return new; } -struct kmod_list *kmod_list_remove(struct kmod_list *list) +/** + * kmod_list_remove: + * @list: the element of the list to remove + * + * Removes and frees the element @list from the list it is a member of. + * + * Returns: the new list head value. + */ +KMOD_EXPORT struct kmod_list *kmod_list_remove(struct kmod_list *list) { struct list_node *node; @@ -202,7 +210,17 @@ struct kmod_list *kmod_list_remove(struct kmod_list *list) return container_of(node, struct kmod_list, node); } -struct kmod_list *kmod_list_remove_data(struct kmod_list *list, +/** + * kmod_list_remove_data: + * @list: the head of the list + * @data: pointer to the data element to remove + * + * Gets the list head @list, searches for an entry, contaning + * data pointer @data and if finds, removes the element from the list. + * + * Returns: the new list head value. + */ +KMOD_EXPORT struct kmod_list *kmod_list_remove_data(struct kmod_list *list, const void *data) { struct kmod_list *itr; @@ -312,3 +330,17 @@ KMOD_EXPORT struct kmod_list *kmod_list_last(const struct kmod_list *list) return NULL; return container_of(list->node.prev, struct kmod_list, node); } + +/** + * kmod_list_data: + * @list: list element to extract data pointer from + * + * Returns the @data pointer from the list entry + * to keep the kmod_list structure opaque + */ +KMOD_EXPORT void *kmod_list_data(const struct kmod_list *list) +{ + if (list == NULL) + return NULL; + return list->data; +} diff --git a/libkmod/libkmod.h b/libkmod/libkmod.h index f9e33c6cde90..a720236dd353 100644 --- a/libkmod/libkmod.h +++ b/libkmod/libkmod.h @@ -87,6 +87,11 @@ struct kmod_list *kmod_list_next(const struct kmod_list *list, struct kmod_list *kmod_list_prev(const struct kmod_list *list, const struct kmod_list *curr); struct kmod_list *kmod_list_last(const struct kmod_list *list); +struct kmod_list *kmod_list_append(struct kmod_list *list, const void *data) __attribute__((warn_unused_result)) __attribute__((nonnull(2))); +struct kmod_list *kmod_list_remove(struct kmod_list *list) __attribute__((warn_unused_result)); +struct kmod_list *kmod_list_remove_data(struct kmod_list *list, + const void *data) __attribute__((warn_unused_result)) __attribute__((nonnull(2))); +void *kmod_list_data(const struct kmod_list *list); #define kmod_list_foreach(list_entry, first_entry) \ for (list_entry = first_entry; \
The library uses list functions to create lists internally and provides to the clients immutable lists and only functions to traverse them. It may be useful to create own lists in the kmod utilities, so export functions for lists creation as well (as it's done for arrays). The following functions affected (needed for the following depmod modifications): kmod_list_append() kmod_list_remove() kmod_list_remove_data() The patch also adds kmod_list_data() accessor to keep the struct kmod_list opaque. Signed-off-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com> --- libkmod/libkmod-internal.h | 4 ---- libkmod/libkmod-list.c | 36 ++++++++++++++++++++++++++++++++++-- libkmod/libkmod.h | 5 +++++ 3 files changed, 39 insertions(+), 6 deletions(-)