linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bob Copeland <me@bobcopeland.com>
To: Henning Rogge <hrogge@gmail.com>
Cc: linux-wireless@vger.kernel.org, Thomas Pedersen <thomas@noack.us>,
	Yeoh Chun-Yeow <yeohchunyeow@gmail.com>,
	Johannes Berg <johannes@sipsolutions.net>
Subject: Re: [RFC Patch] Unify mpp/mesh_path handling for Mac 802.11s
Date: Thu, 22 May 2014 15:27:20 -0400	[thread overview]
Message-ID: <20140522192720.GA13440@localhost> (raw)
In-Reply-To: <3893194.GDQagdLGN9@desktop.local>

On Thu, May 22, 2014 at 05:06:21PM +0200, Henning Rogge wrote:
> From: Henning Rogge <hrogge@gmail.com>
> 
> This patch is a preparation for exporting the MPP data of the 802.11s
> implementation via netlink to userspace. It unifies the content of the
> mesh_paths and mpp_paths tables in mesh_pathtbl.c without changing
> the behavior of the code.
> 
> Signed-off-by: Henning Rogge <hrogge@gmail.com>

I think I fall on the side of your earlier assessment that they
hold different things and should stay in different tables, even though
there are 200 lines of identical code here.  Maybe some bits could
be shared without sharing the data and changing the API?

> -static struct mesh_path *mpath_lookup(struct mesh_table *tbl, const u8 *dst,
> -				      struct ieee80211_sub_if_data *sdata)
> +/**
> + * mesh_path_lookup - look up a path in the mesh path table
> + * @sdata: local subif
> + * @dst: hardware address (ETH_ALEN length) of destination
> + * @is_proxied: true to lookup mpp entries, false otherwise

Also, I don't like adding random boolean variables to water down what
this function does.  It means when looking at the caller you have to go
back to the definition to see just what is going on here.

We do mpp_path_lookup exactly twice so it seems weird to have to
change all of the mpath_lookup callers too.

-- 
Bob Copeland %% www.bobcopeland.com

  parent reply	other threads:[~2014-05-22 19:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22 15:06 [RFC Patch] Unify mpp/mesh_path handling for Mac 802.11s Henning Rogge
2014-05-22 15:15 ` Johannes Berg
2014-05-22 15:21   ` Henning Rogge
2014-05-22 15:25     ` Johannes Berg
2014-05-22 19:27 ` Bob Copeland [this message]
2014-05-22 19:31   ` Henning Rogge
2014-05-23  9:08     ` Yeoh Chun-Yeow
2014-05-23 10:52       ` Henning Rogge
2014-05-23 20:57         ` Bob Copeland
2014-05-26  6:47           ` Yeoh Chun-Yeow
2014-05-26  9:37             ` Henning Rogge
2014-05-26 10:26               ` Yeoh Chun-Yeow

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=20140522192720.GA13440@localhost \
    --to=me@bobcopeland.com \
    --cc=hrogge@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=thomas@noack.us \
    --cc=yeohchunyeow@gmail.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).