[Olsr-dev] "sendto(v4): Network is unreachable"

[Hans-Christoph Steiner]

On 02/14/2013 01:05 PM, Ferry Huberts wrote:
> 
> 
> On 14/02/13 18:58, Hans-Christoph Steiner wrote:
>>
>>
>> On 02/14/2013 12:32 PM, Ferry Huberts wrote:
>>>
>>>
>>> On 14/02/13 18:30, Ferry Huberts wrote:
>>>>
>>>>
>>>> On 14/02/13 18:17, Hans-Christoph Steiner wrote:
>>>>>
>>>>>
>>>>> On 02/14/2013 12:12 PM, Henning Rogge wrote:
>>>>>> On Thu, Feb 14, 2013 at 5:52 PM, Hans-Christoph Steiner
>>>>>> <(spam-protected)> wrote:
>>>>>>> If dyngw/dyngwplain only work with the Linux kernel, then why does the
>>>>>>> olsrd/Makefile include them both in non-Linux OSs:
>>>>>>>
>>>>>>> ifeq ($(OS),linux)
>>>>>>> SUBDIRS = arprefresh bmf dot_draw dyn_gw dyn_gw_plain httpinfo
>>>>>>> jsoninfo mdns
>>>>>>> mini nameservice p2pd pgraph pud quagga secure sgwdynspeed txtinfo
>>>>>>> watchdog
>>>>>>> else
>>>>>>> ifeq ($(OS),win32)
>>>>>>> SUBDIRS := dot_draw httpinfo jsoninfo mini pgraph secure txtinfo
>>>>>>> else
>>>>>>> ifeq ($(OS),android)
>>>>>>> SUBDIRS := arprefresh bmf dot_draw dyn_gw_plain httpinfo jsoninfo mini
>>>>>>> nameservice pgraph pud secure sgwdynspeed txtinfo watchdog
>>>>>>> else
>>>>>>> SUBDIRS := dot_draw dyn_gw dyn_gw_plain httpinfo jsoninfo mini
>>>>>>> nameservice
>>>>>>> pgraph secure txtinfo watchdog
>>>>>>> endif
>>>>>>> endif
>>>>>>> endif
>>>>>>
>>>>>> Because someone added it in 2008 when the makefile got a "other"
>>>>>> category (instead of just "win32" and "not win32")... and nobody ever
>>>>>> complained.
>>>>>>
>>>>>> @Ferry: I am pretty sure /proc doesn't exist on MacOS... do you agree?
>>>>>>
>>>>
>>>>
>>>> I know nothing about Mac, or Windows for that matter.
>>>> Linux is the only thing that matters to me.
>>>>
>>>> As Henning said, that plugin is _old_
>>>>
>>>>>> Henning
>>>>>
>>>>> Mac OS X definitely does not have /proc.  GNU Hurd does not have
>>>>> /proc.  It
>>>>> looks like FreeBSD used to have /proc but now its deprecated:
>>>>>
>>>>> http://www.freebsd.org/doc/en/articles/linux-users/procfs.html
>>>>>
>>>>> But apparently, you can use linprocfs in FreeBSD to get a
>>>>> Linux-compatible
>>>>> /proc.  I think it makes sense to remove dyn_gw and dyn_gw_plain from the
>>>>> default 'other' build, then for people who install linprocfs on
>>>>> FreeBSD, then
>>>>> can always do 'make dyn_gw'.
>>>>>
>>>>> If everyone agrees, I'll go ahead and commit.
>>>>>
>>>>
>>>> Sure, remove it from the SUBDIRS, but _also_ please add a check in the
>>>> makefiles of those plugins, something like the pud plugin does:
>>>>
>>>>>
>>>>> SUPPORTED = 0
>>>>> ifeq ($(OS),linux)
>>>>> SUPPORTED = 1
>>>>> endif
>>>>> ifeq ($(OS),android)
>>>>> SUPPORTED = 1
>>>>> endif
>>>>
>>>
>>>
>>> paste some more of the example....
>>>
>>>
>>>>
>>>> ifeq ($(SUPPORTED),0)
>>>>
>>>> .PHONY: all default_target install clean
>>>>
>>>> all: default_target
>>>>
>>>> default_target install clean:
>>>>      @echo "*** $(PLUGIN_NAME) plugin not supported on $(OS), sorry!"
>>>>
>>>> else
>>>>    ..........
>>
>> Since we only really know that /proc is not used by default, but we don't know
>> whether there are ways of adding /proc like FreeBSD has, I think it makes
>> sense to just remove it from the default build.  I think it should remain an
>> option for someone to build those plugins on any platform if they specifically
>> choose to do so (i.e. make dyn_gw).
>>
> 
> I asked that you'd add the checks for a reason...
> If we know that it only works on Linux then that must be made clear:
> when someone compiles it on an unsupported platform he'll then receive a nice
> compile error. He can then decide to port it if he really wants to use it, or
> refrain from using it.
> 
> Please add the checks

I think such a compile error is counterproductive.  We do not know these
platforms, therefore we do not know for sure that there is no way to use
/proc.  Why should we prevent people who want to build it from building it?
For people who just want to have what is known to work on their OS, they can
use 'make build_all' and never have any idea about this issue.

For someone hacking trying to get dyn_gw working on their OS, such a compile
error will just be a pointless hurdle for them.

.hc