[Olsr-dev] lua in olsrd sources

[Hans-Christoph Steiner]

On 02/07/2012 11:37 AM, Bernd Petrovitsch wrote:
> On Die, 2012-02-07 at 10:11 -0500, Hans-Christoph Steiner wrote:
>> On Feb 4, 2012, at 7:51 AM, Bernd Petrovitsch wrote:
> [....]
>>> Perhaps Andreas T. - from which I more or less took over maintainership
>>> ages ago - knows how/when/why the LUA interpreter ended up in there.
>>
>> Its easy enough to make it build against an external version of Lua,
>> and Lua is included in Debian, Ubuntu, Fedora, Mac OS X/Fink,
>> MacPorts, Cygwin, etc.  Its also easy to build using MinGW.
> 
> Very probably - that is really not the problem.
> But not the whole world is some well-known Linux distro on a
> IBM-compatible PC (and from the pure deployed numbers of systems they
> are actually not really that relevant. Yes, the PC world doesn't know or
> fail to accept that. But that's another story ...).
> 
>> I think the path of least resistance would be to remove the lua
>> sources and just build against external sources.  I can do the build
>> part.
> 
> Strategically olsrd never used external libs (except of course libc but
> that is always a special case).
> One reason was that there were no real tempting candidates for anything,
> e.g.
> - glib, liboop or something similar for the main-loop.
> - APR or something similar to "ease porting"</salesdroid> is
>   IMHO for olrsd far more work to integrate, use and maintain then the
>   gain because olsrd is quite small and compact anyways.
> - a lib for the Dijkstra algo: I don't know if such a beast actually
>   exists.
> 
> The next reason is that that lib should exist/work/be ported on all
> supported platforms - at that time Linux distros, openwrt, *BSD, CygWin.
> 
> In an ideal world, you have cooperative people with sufficient know-how
> and interest to work with who - at least - try new versions out and help
> to nail bugs - both build time and run-time.
> Well, the world was (much) less then ideal (and many thanks once more
> for those who tried to make the world more ideal and who sent not only
> bug reports but also patches fixing it locally for them at least).
> 
> The 3rd reason is that using external libs usually
> a) implies run-time bloat because it is quite unlikely that a daemon
>    needs really all of it.
>    IIRC we actually avoided libm explicitly.
>    So think twice about it in the embedded world.
>    And you very probably get the run-time bloat even if you link the
>    lib statically hoping the linker removes all unused parts (because
>    most libs tend to have lots internal stuff which is not trivially
>    avoidable).
>    Try that with GNU-libc and see how much code is pulled in ....
> b) implies another abstraction layer (the API of the lib) and at that
>    time olsrd already had (far) too many of them internally (and Hannes
>    Gredler and I tried to kill some of them mainly because the didn't
>    buy anything and just costs performance and source code and run-time
>    code bloat).
>    Don't know about today.
> c) you have to cope with their API - which maybe easy or not.
> d) possibly handle with a changing API - both feature-wise and bug-wise.
>    Compile-testing is easy, but that won't catch all changes -
>    especially not the semantic ones.
>    In the Linux distro area, the distributor handles updates etc. here,
>    but who does it for openwrt, CygWin or *BSD?
>    And there people actually update there systems once in a while too.
> 
> And the main issue with external libs is that historically openwrt
> running on Linksys with 16 MB RAM[0] and other (somewhat) embedded stuff
> were the main platform - and some not some random "PC Linux distro".
> I don't know how that is today - Henning should know.
> 
> IMHO it's the maintainers opinion that counts and, consequently,
> decision - the above is just my experience with (real) embedded Linux
> systems[1] and view on that issue (and I purposely do not write (more
> about;-) what I should have done ages ago or what I would do today if I
> were in that position;-).
> 
> Kind regards,
> 	Bernd
> 
> [0]: That was - later on - the "L" edition. A stripped down version of
>      openwrt (no webinterface or other bells and whistles) actually ran
>      on the newer, smaller ones with smaller ones - 8 MB RAM.
> [1]: Hardware with 128 MB RAM and 1 GB Flash-RAM is easy - just run some
>      stripped down Linux distro on them. But there was hardware with 4
>      MB Flash-RAM and and 16 MB RAM.

Thanks for the thorough explanation, I agree it makes perfect sense for
a project like olsrd to avoid all libraries.  My essential point was not
that olsrd should only target systems that include Lua, but rather when
a system includes Lua, olsrd should use that one over the included one.
 This is Debian policy, for example.

Removing the Lua code from olsrd is much less important, its fine by me
if the Lua sources stay there.  But Lua is a program that was built to
be embedded, so its easy to build on just about any platform.
Therefore, it would be easy for someone to download lua and included it
into olsrd.  Having the sources there means that people will likely use
the old version included with olsrd, security bugs and all, rather than
get an up-to-date release.

For a fun diversion, I've done a fair amount of work on very limited
platforms, for example, I helped port Pure Data, a synthesis engine, to
1st gen iPods, so 83Mhz ARM with 8MB RAM.  This was a Linux kernel with
not much else but a super simple GUI, and the version of Pd was ported
to use ints as much as possible, where normally the synthesis is all floats:
http://www.youtube.com/watch?v=bMtOKvJFetk

.hc