From: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: linux-modules <linux-modules@vger.kernel.org>,
Mian Yousaf Kaukab <yousaf.kaukab@suse.com>,
bjorn.andersson@linaro.org
Subject: Re: [PATCH RFC 2/3] libkmod: list: export list handling functions
Date: Mon, 20 Feb 2017 16:22:41 +0200 [thread overview]
Message-ID: <xuny4lzpueku.fsf@redhat.com> (raw)
In-Reply-To: <CAKi4VAJ4kQucKsj3SYZzzRJU9KfEQoDwgQfnWYDki3Gfn5UG1Q@mail.gmail.com> (Lucas De Marchi's message of "Mon, 13 Feb 2017 00:05:07 -0800")
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?
--
WBR,
Yauheni Kaliuta
next prev parent reply other threads:[~2017-02-20 14:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-08 16:45 [PATCH v1 1/2] testsuite: depmod: add module dependency outside cyclic chain Mian Yousaf Kaukab
2016-11-08 16:45 ` [PATCH v1 2/2] depmod: ignore related modules in depmod_report_cycles Mian Yousaf Kaukab
2016-11-09 0:40 ` Lucas De Marchi
2016-11-09 2:59 ` Yauheni Kaliuta
2016-11-09 9:17 ` Mian Yousaf Kaukab
2016-11-09 11:23 ` Yauheni Kaliuta
2016-11-11 11:43 ` [PATCH RFC 0/3] Proposal for cycles handling Yauheni Kaliuta
2016-11-11 11:43 ` [PATCH RFC 2/3] libkmod: list: export list handling functions Yauheni Kaliuta
2017-02-13 8:05 ` Lucas De Marchi
2017-02-20 14:22 ` Yauheni Kaliuta [this message]
2017-02-22 5:26 ` Lucas De Marchi
2017-02-22 9:41 ` [PATCH v3 0/2] Proposal for cycles handling Yauheni Kaliuta
2017-02-22 9:41 ` [PATCH v3 1/2] testsuite: depmod: check netsted loops reporting Yauheni Kaliuta
2017-02-22 9:41 ` [PATCH v3 2/2] depmod: handle nested loops Yauheni Kaliuta
2017-02-23 22:30 ` Lucas De Marchi
2016-11-11 11:43 ` [PATCH RFC 3/3] " Yauheni Kaliuta
2017-02-13 8:30 ` Lucas De Marchi
2017-02-20 14:16 ` Yauheni Kaliuta
2017-02-13 8:16 ` [PATCH RFC 0/3] Proposal for cycles handling Lucas De Marchi
2017-02-13 9:56 ` Yauheni Kaliuta
2017-02-13 8:32 ` Lucas De Marchi
2017-02-20 14:18 ` [PATCH RFC v2 0/2] " Yauheni Kaliuta
2017-02-20 14:18 ` [PATCH RFC v2 1/2] testsuite: depmod: check netsted loops reporting Yauheni Kaliuta
2017-02-20 14:19 ` [PATCH RFC v2 2/2] depmod: handle nested loops Yauheni Kaliuta
2016-11-09 0:29 ` [PATCH v1 1/2] testsuite: depmod: add module dependency outside cyclic chain Lucas De Marchi
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=xuny4lzpueku.fsf@redhat.com \
--to=yauheni.kaliuta@redhat.com \
--cc=bjorn.andersson@linaro.org \
--cc=linux-modules@vger.kernel.org \
--cc=lucas.de.marchi@gmail.com \
--cc=yousaf.kaukab@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).