linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: pat-lkml <pat-lkml@erley.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: Userspace tools: Roadmap?
Date: Fri, 12 Dec 2008 11:24:40 -0500	[thread overview]
Message-ID: <1229099080.14423.15.camel@dv> (raw)
In-Reply-To: <4941EF69.5040108@erley.org>

On Thu, 2008-12-11 at 23:58 -0500, pat-lkml wrote:
> Attached is a newer 'better' version based off of how hostapd is
> handling this.  This patch adds an option, CONFIG_LIBNL20, which enables
> LIBNL20 compatibility.  I haven't ever been able to get iw to build with
> libnl-1.0 or libnl-1.1 on my system, so I haven't been able to test
> that, but it should work.
...
> +ifeq ($(NLVERSION), 2.0)
> +CFLAGS += `pkg-config --cflags libnl-2.0` -DCONFIG_LIBNL20
> +LDFLAGS += `pkg-config --libs libnl-2.0`
> +LIBS += -lnl -lnl-genl -lnl-nf -lnl-route
> +NLTESTVERSION = 2.0
> +else
> +CFLAGS += `pkg-config --cflags libnl-1`
> +LDFLAGS += `pkg-config --libs libnl-1.0`

I think you mean "libnl-1" without ".0" here.

> +LIBS += -lnl
> +NLTESTVERSION = 1
> +endif

It would be better to have a variable for pkg-config name of the
library, that is "libnl-1" or "libnl-2.0".

LDCONFIG and LIBS could both be derived from pkg-config by using
--libs-only-l, --libs-only-other and --libs-only-L.  --libs-only-l goes
to LIBS, --libs-only-L goes to LDFLAGS and I guess --libs-only-other
could go to LDFLAGS as well.

>  version_check:
> -	@if ! pkg-config --atleast-version=$(NLVERSION) libnl-1; then echo
> "You need at least libnl version $(NLVERSION)"; exit 1; fi
> +	@if ! pkg-config --atleast-version=$(NLVERSION)
> libnl-$(NLTESTVERSION); then echo "You need at least libnl version
> $(NLVERSION)"; exit 1; fi

I would consider autodetection for libnl version here if it's not too
hard.

> +#ifdef CONFIG_LIBNL20
> +/* libnl 2.0 compatibility code */
> +#define nl_handle_alloc_cb nl_socket_alloc_cb
> +#define nl_handle_alloc nl_socket_alloc
> +#define nl_handle_destroy nl_socket_free
> +#endif /* CONFIG_LIBNL20 */

Please use macros with arguments to ensure their correct number.

>From my experience with external Linux drivers (MadWifi in particular),
it's easier to follow the current API and provide compatibility for the
old API, not the other way around.  This way, it's easier to track
further API changes.  Also, the new API is usually easier to understand.

> +#ifdef CONFIG_LIBNL20
> +	if (genl_ctrl_alloc_cache(state->nl_handle, &(state->nl_cache))) {
> +#else
>  	state->nl_cache = genl_ctrl_alloc_cache(state->nl_handle);
>  	if (!state->nl_cache) {
> +#endif

Perhaps you could provide a compatibility genl_ctrl_alloc_cache() macro
for libnl1 and avoid this ifdef?

-- 
Regards,
Pavel Roskin

  reply	other threads:[~2008-12-12 16:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-07 23:29 Userspace tools: Roadmap? Dan E
2008-12-08  7:02 ` Rami Rosen
2008-12-08  8:13 ` Johannes Berg
2008-12-08 23:18   ` Dan E
2008-12-08 23:26     ` Johannes Berg
2008-12-08 23:52       ` pat-lkml
2008-12-09  0:02         ` Johannes Berg
2008-12-09  0:08           ` pat-lkml
2008-12-12  4:58           ` pat-lkml
2008-12-12 16:24             ` Pavel Roskin [this message]
2008-12-12 21:58               ` Johannes Berg
2008-12-12 22:37                 ` pat-lkml
2008-12-12 22:38                   ` Johannes Berg
2008-12-12 23:36                     ` pat-lkml
2008-12-12 23:42                       ` pat-lkml
2008-12-12 23:50                         ` Johannes Berg
2008-12-12 23:48                     ` pat-lkml
2008-12-13  0:05                       ` Johannes Berg
2008-12-13  0:10                         ` pat-lkml
2008-12-13  0:10                           ` Johannes Berg
2008-12-09  0:43       ` Dan E
2008-12-09  0:51         ` Johannes Berg
2008-12-09  1:01           ` Dan E
2008-12-09  1:05             ` Johannes Berg
2009-01-15  7:52   ` David Shwatrz
2009-01-15  9:35     ` Johannes Berg

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=1229099080.14423.15.camel@dv \
    --to=proski@gnu.org \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=pat-lkml@erley.org \
    /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).