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

[Henning Rogge]

In this case we would have different plugins for the "wireless data
gathering", one for each operation system.

If we get to this point, we might of course think about joining the
plugins in a common name.

Henning

On Sat, Jul 14, 2012 at 4:40 AM, Hans-Christoph Steiner
<(spam-protected)> wrote:
>
> 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
>>
>>
>>
>



-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."