[Olsr-dev] NL80211 link quality patch and GIT repository

[Kees-Jan Hermans]

Henning Rogge,

I've looked (and did some Googling on the matter) - I understand that
your vision of gathering L2 availability values between peers using
Cisco DLEP inside a seperate executable ?

KJ

On Mon, 2012-07-09 at 21:58 +0200, Henning Rogge wrote:
> Can you take a look at this two files?
> 
> http://olsr.org/git/?p=dlep_app.git;a=blob;f=src/olsr_layer2.h;h=17afbfec1f9457873016d18fa42a24f93376fe6f;hb=master
> http://olsr.org/git/?p=dlep_app.git;a=blob;f=src/olsr_layer2.c;h=feed068def034752476d6a18556493ee56ff1de6;hb=master
> 
> That is the "in between datastructure" (or something similar) I
> designed for OLSRv2... something between "collects layer-2 data" and
> "use layer-2 data to build the metric".
> 
> What do you think about the idea?
> 
> Henning Rogge
> 
> On Mon, Jul 9, 2012 at 9:49 PM, Kees-Jan Hermans <(spam-protected)> wrote:
> > Well,
> >
> > to be precise, I encountered two recent versions of Debian where one
> > would have all userland wireless functionality in libnl, and it would
> > have API-version #defines (CONFIG_LIBNL20 and CONFIG_LIBNL30), and one
> > that had that library completely split up (in libnl, libnl-nf,
> > libnl-cli, libnl-route, libnl-genl), and none of those #defines. So I
> > thought, I'd approach this in the following manner:
> >
> > 1) Our patch currently only works on Linux (so WIN32 and BSD would have
> > to have some elegant message saying 'Sorry, you can't use this right
> > now' - this is going to be solved in the code by a '#ifdef __linux__',
> > but in the makefile I'd need to be able to switch on the fact that we're
> > using Linux or not (I think I've seen a few instances of that in the
> > Makefiles already), in order to determine whether or not it's going to
> > run the script at all.
> >
> > 2) Upon discovery of a few Linux NL-quirks by the script, either a
> > Makefile inclusion file is produced, or the present Makefile is altered,
> > whichever has your preference (the former has the advantage that running
> > the script doesn't alter the GIT state of the present Makefile).
> >
> > In the absence of a proper 'configure' script, this is the only elegant
> > solution I could think of.
> >
> > KJ
> >
> > On Mon, 2012-07-09 at 15:17 -0400, Hans-Christoph Steiner wrote:
> >> Sure, that's possible with make, which headers and functions are you talking about?
> >>
> >> My guess is that most likely, you'll want to use #ifdef macros.
> >>
> >> .hc
> >>
> >> On Jul 9, 2012, at 11:32 AM, Kees-Jan Hermans wrote:
> >>
> >> > Ok, thanks. Turns out that what I thought was new, was old, and vice
> >> > versa. Spent some of the weekend adapting a patch against the old code.
> >> > My mistake I suppose - teach me the basics of this here project ;-)
> >> >
> >> > Anyway, some patching up was necessary anyhow (mostly, unfortunately,
> >> > due to the fact that there is no stable nl80211 userland API on Linux,
> >> > differing wildly among distributions and no real sure way to know what
> >> > version you're dealing with on the basis of #defines and whatnot)
> >> >
> >> > Which leads me to another question: is there something in the course of
> >> > 'make' that I could use to create a 'configure' like situation
> >> > (discovery of certain uses of header files, function prototypes and
> >> > defines) ?
> >> >
> >> > Sincerely,
> >> >
> >> > KJ
> >> >
> >> > On Mon, 2012-07-09 at 16:49 +0200, Henning Rogge wrote:
> >> >> On 07/09/2012 04:45 PM, Kees-Jan Hermans wrote:
> >> >>> Dear all,
> >> >>>
> >> >>> I've been working on renewing the patch for using wireless lan metrics
> >> >>> as part of the link quality cost calculation, but I've been a bit
> >> >>> confused as to how the repository works; it seems that the default
> >> >>> 'master' branch is old, and the 'stable' branch is where everyone is
> >> >>> committing their new code against. Is that correct? I'm just asking,
> >> >>> because in other places, such nomenclature would suggest a different,
> >> >>> and opposite, function.
> >> >>
> >> >> Yes, thats right.
> >> >>
> >> >> We were also in the process of discussing a change in the "where to
> >> >> commit and how to do it" policy here when I got hit by an "eat up a
> >> >> whole week of time" thing...
> >> >>
> >> >> Hope we will restart the discussion soon and sort it out.
> >> >>
> >> >> Henning
> >> >>
> >> >>
> >> >
> >> > --
> >> > Olsr-dev mailing list
> >> > (spam-protected)
> >> > https://lists.olsr.org/mailman/listinfo/olsr-dev
> >>
> >
> > --
> > Olsr-dev mailing list
> > (spam-protected)
> > https://lists.olsr.org/mailman/listinfo/olsr-dev
> 
> 
>