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

[Hans-Christoph Steiner]

Now that might be true, but it could change.

.hc

On 07/13/2012 05:07 PM, Henning Rogge wrote:
> A nl80211 based plugin would not be feasible on non linux-systems anyways.
> 
> Henning
> 
> On Fri, Jul 13, 2012 at 7:46 PM, Hans-Christoph Steiner
> <(spam-protected)> wrote:
>>
>> If you do end up adding libnl support, I would recommend using as
>> specific macros as possible.  It sounds like __linux__ is much too
>> general.  GNU/Linux and Android both define __linux__, for example, and
>> it really means "depends on the Linux kernel".  You might consider
>> __gnu_linux__ if libnl isn't feasible on Android.
>>
>> So for libnl, ideally there would be a macro for libnl, so people who
>> don't have the libnl headers but are building on GNU/Linux would not
>> have issues.
>>
>> .hc
>>
>>
>> On 07/09/2012 03:49 PM, Kees-Jan Hermans 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
> 
> 
>