Upstream has renamed nl_handle to nl_sock. Update crda to the new names
and add #define for libnl-1.1.
Signed-off-by: Pat Erley <[email protected]>
---
I'm not too proud to admit that I did proofread this, twice, and still
missed changing iw to crda in the commit message.
In the future, should I keep pushing these sorts of patches, or should
we back them out and wait for a 'release' of libnl-2.0 and push them all
in then?
diff --git a/crda.c b/crda.c
index afc5df1..f2c471f 100644
--- a/crda.c
+++ b/crda.c
@@ -43,10 +43,11 @@ static inline int __genl_ctrl_alloc_cache(struct
nl_handle *h, struct nl_cache *
}
#define genl_ctrl_alloc_cache __genl_ctrl_alloc_cache
+#define nl_sock nl_handle
#endif /* CONFIG_LIBNL20 */
struct nl80211_state {
- struct nl_handle *nl_handle;
+ struct nl_sock *nl_sock;
struct nl_cache *nl_cache;
struct genl_family *nl80211;
};
@@ -55,22 +56,22 @@ static int nl80211_init(struct nl80211_state *state)
{
int err;
- state->nl_handle = nl_socket_alloc();
- if (!state->nl_handle) {
- fprintf(stderr, "Failed to allocate netlink handle.\n");
+ state->nl_sock = nl_socket_alloc();
+ if (!state->nl_sock) {
+ fprintf(stderr, "Failed to allocate netlink sock.\n");
return -ENOMEM;
}
- if (genl_connect(state->nl_handle)) {
+ if (genl_connect(state->nl_sock)) {
fprintf(stderr, "Failed to connect to generic netlink.\n");
err = -ENOLINK;
- goto out_handle_destroy;
+ goto out_sock_destroy;
}
- if (genl_ctrl_alloc_cache(state->nl_handle, &state->nl_cache)) {
+ if (genl_ctrl_alloc_cache(state->nl_sock, &state->nl_cache)) {
fprintf(stderr, "Failed to allocate generic netlink cache.\n");
err = -ENOMEM;
- goto out_handle_destroy;
+ goto out_sock_destroy;
}
state->nl80211 = genl_ctrl_search_by_name(state->nl_cache, "nl80211");
@@ -84,8 +85,8 @@ static int nl80211_init(struct nl80211_state *state)
out_cache_free:
nl_cache_free(state->nl_cache);
- out_handle_destroy:
- nl_socket_free(state->nl_handle);
+ out_sock_destroy:
+ nl_socket_free(state->nl_sock);
return err;
}
@@ -93,7 +94,7 @@ static void nl80211_cleanup(struct nl80211_state *state)
{
genl_family_put(state->nl80211);
nl_cache_free(state->nl_cache);
- nl_socket_free(state->nl_handle);
+ nl_socket_free(state->nl_sock);
}
static int reg_handler(struct nl_msg __attribute__((unused)) *msg,
@@ -294,7 +295,7 @@ int main(int argc, char **argv)
if (!cb)
goto cb_out;
- r = nl_send_auto_complete(nlstate.nl_handle, msg);
+ r = nl_send_auto_complete(nlstate.nl_sock, msg);
if (r < 0) {
fprintf(stderr, "Failed to send regulatory request: %d\n", r);
@@ -306,7 +307,7 @@ int main(int argc, char **argv)
nl_cb_err(cb, NL_CB_CUSTOM, error_handler, NULL);
if (!finished) {
- r = nl_wait_for_ack(nlstate.nl_handle);
+ r = nl_wait_for_ack(nlstate.nl_sock);
if (r < 0) {
fprintf(stderr, "Failed to set regulatory domain: "
"%d\n", r);
On Wed, 2009-01-28 at 18:44 -0500, pat-lkml wrote:
> Upstream has renamed nl_handle to nl_sock. Update crda to the new names
> and add #define for libnl-1.1.
But libnl-2.0 comes with a define too:
#define nl_handle nl_sock
you just need to include the right headers, no?
johannes
On Wed, 2009-01-28 at 19:21 -0500, pat-lkml wrote:
> Johannes Berg wrote:
> > On Wed, 2009-01-28 at 18:44 -0500, pat-lkml wrote:
> >> Upstream has renamed nl_handle to nl_sock. Update crda to the new names
> >> and add #define for libnl-1.1.
> >
> > But libnl-2.0 comes with a define too:
> > #define nl_handle nl_sock
> >
> > you just need to include the right headers, no?
> >
> > johannes
>
> dunno.... but I can't find it:
>
> libnl $ egrep "#define nl_handle" * -r
> libnl $ git pull
> Already up-to-date.
Ah. Grr. Just recently removed.
johannes
On Wed, Jan 28, 2009 at 03:44:08PM -0800, pat-lkml wrote:
> Upstream has renamed nl_handle to nl_sock. Update crda to the new names
> and add #define for libnl-1.1.
>
> Signed-off-by: Pat Erley <[email protected]>
> ---
>
> I'm not too proud to admit that I did proofread this, twice, and still
> missed changing iw to crda in the commit message.
>
> In the future, should I keep pushing these sorts of patches, or should
> we back them out and wait for a 'release' of libnl-2.0 and push them all
> in then?
I'll gladly take them, sure, actually thanks!
Luis
Johannes Berg wrote:
> On Wed, 2009-01-28 at 18:44 -0500, pat-lkml wrote:
>> Upstream has renamed nl_handle to nl_sock. Update crda to the new names
>> and add #define for libnl-1.1.
>
> But libnl-2.0 comes with a define too:
> #define nl_handle nl_sock
>
> you just need to include the right headers, no?
>
> johannes
dunno.... but I can't find it:
libnl $ egrep "#define nl_handle" * -r
libnl $ git pull
Already up-to-date.
Pat
On Wed, 2009-01-28 at 19:39 -0500, pat-lkml wrote:
> Which leads back around to my question, should I continue pushing
> patches like this your way (after making sure the right patch is on the
> right e-mail with the right description),
Heh :) Also make sure your patch isn't line-wrapped next time, please.
The iw resend was line-wrapped.
> or do we want to wait and I'll
> just maintain the patches outside of git, and push them once libnl-2.0
> hits? On one hand, it makes testing both versions easier, on the other,
> it makes a lot of little 'fix' commits like this. I have no issues
> maintaining these sorts of patches, but I don't want to do it if you
> don't want them.
No, it's fine, I've committed this now, thanks. I had just thought it
ought to work, based on testing with git snapshot a couple of weeks
ago...
Not that libnl-2.0 compiles cleanly on my system...
johannes
Johannes Berg wrote:
> On Wed, 2009-01-28 at 19:21 -0500, pat-lkml wrote:
>> Johannes Berg wrote:
>>> On Wed, 2009-01-28 at 18:44 -0500, pat-lkml wrote:
>>>> Upstream has renamed nl_handle to nl_sock. Update crda to the new names
>>>> and add #define for libnl-1.1.
>>> But libnl-2.0 comes with a define too:
>>> #define nl_handle nl_sock
>>>
>>> you just need to include the right headers, no?
>>>
>>> johannes
>> dunno.... but I can't find it:
>>
>> libnl $ egrep "#define nl_handle" * -r
>> libnl $ git pull
>> Already up-to-date.
>
> Ah. Grr. Just recently removed.
>
> johannes
Which leads back around to my question, should I continue pushing
patches like this your way (after making sure the right patch is on the
right e-mail with the right description), or do we want to wait and I'll
just maintain the patches outside of git, and push them once libnl-2.0
hits? On one hand, it makes testing both versions easier, on the other,
it makes a lot of little 'fix' commits like this. I have no issues
maintaining these sorts of patches, but I don't want to do it if you
don't want them.
Pat