From: Stephen Hemminger <shemminger@vyatta.com>
To: Yegor Yefremov <yegorslists@googlemail.com>
Cc: netdev@vger.kernel.org
Subject: Re: iproute2: iplink_ stuff cleanup
Date: Mon, 19 Mar 2012 15:53:27 -0700 [thread overview]
Message-ID: <20120319155327.089d6495@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <CAGm1_kvbqOtArw4dUpnzTRB1JtfBCaAAeyFYCPrcaGYUF10NSg@mail.gmail.com>
On Mon, 19 Mar 2012 23:22:59 +0100
Yegor Yefremov <yegorslists@googlemail.com> wrote:
> >> I'm still struggling to get ip/iplink_* routines to show up in
> >> Android's ip binary
> >> (https://groups.google.com/d/topic/android-building/yjV4iYnT1Zc/discussion).
> >> I've looked at the algorithm that is used to access those functions
> >> (like can_parse_opt, vlan_parse_opt etc.)
> >>
> >> snprintf(buf, sizeof(buf), LIBDIR "/ip/link_%s.so", id);
> >> dlh = dlopen(buf, RTLD_LAZY);
> >> if (dlh == NULL) {
> >> /* look in current binary, only open once */
> >> dlh = BODY;
> >> if (dlh == NULL) {
> >> dlh = BODY = dlopen(NULL, RTLD_LAZY);
> >> if (dlh == NULL)
> >> return NULL;
> >> }
> >> }
> >>
> >> snprintf(buf, sizeof(buf), "%s_link_util", id);
> >> l = dlsym(dlh, buf);
> >> if (l == NULL)
> >> return NULL;
> >>
> >> as far as I can see from the ip/Makefile there are no dynamic libs
> >> like /ip/link_%s.so. Wouldn't it be simpler to let all iplink_*
> >> objects to export their interfaces via header files and just make a
> >> table in ip/iplink.c to hold protocol ID and pointer at link_utils
> >> struct.
> >>
> >> struct link_util can_link_util = {
> >> .id = "can",
> >> .maxattr = IFLA_CAN_MAX,
> >> .parse_opt = can_parse_opt,
> >> .print_opt = can_print_opt,
> >> .print_xstats = can_print_xstats,
> >> };
> >>
> >> Am I missing something?
> >>
> >> Regards,
> >> Yegor
> >
> > Ip utilities have dynamic extensibility, it is possible for someone
> > to add shared libraries for new functionality. This is a cool feature
> > but isn't used directly by the standard code. It does use it indirectly
> > by using dlopen() to find functions locally.
> >
> > Think of it as introspection in C.
> >
> > I won't take it out of the standard version, but you may have to find
> > another way to handle it on the Android universe.
>
> The solution turned out to be simple:
> https://android-review.googlesource.com/#/c/34240/.
> -Wl,--no-gc-sections did the job.
>
> Can you suggest some more pro arguments for dynamic method of
> exporting API routines?
You could make it optional on your platform, but for mainline Linux
it has been around long enough that someone surely depends on it.
prev parent reply other threads:[~2012-03-19 22:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-15 13:53 iproute2: iplink_ stuff cleanup Yegor Yefremov
2012-03-15 16:18 ` Stephen Hemminger
2012-03-19 22:22 ` Yegor Yefremov
2012-03-19 22:53 ` Stephen Hemminger [this message]
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=20120319155327.089d6495@nehalam.linuxnetplumber.net \
--to=shemminger@vyatta.com \
--cc=netdev@vger.kernel.org \
--cc=yegorslists@googlemail.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