Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I got a little curious about what's actually running in some of the different packages that are compiled for the dns-323 and dns-321 as well as the stuff that's on there natively.
In particular, I was trying to figure out what the difference would be between say a package in ffp, one from optware, one from a chroot debian, and the one that's in the firmware. (Note I've left out armedslack or any "reloaded" variant because that introduces the added complexity of a different kernel.) This led to a bunch of questions.
Is there a simple answer to the question of what the differences are between these things?
I'm guessing that it has something to do with toolchain or shared-libraries against which they were compiled as well as some other dependencies, ...
Also, there should be some reason why these distributions do not compile against the uClibc that is provided natively. Is that uClibc so cut down that it is not useful for anything beyond the code that's in the flash, or are headers missing, or ...?
It looks like the ffp distributed code is very picky about making sure that it picks up its libraries from /ffp/lib. What is the reason for that?
At least for packages that can be compiled that way, it seems like there would be some advantage to compiling against the uClibc that is provided natively since that would optimize memory use, paging, ...
A final question that this brings up is the issue of selectively replacing things in the flash. The DNS-321 has a decent sized (16M as opposed to 8 in the 323) flash, so would it be possible to get a more full featured uClibc in there without completely reflashing?
Before I started wading through source code and build scripts I thought I'd ask here. I suspect that some of the uber-gurus like Fonz may know the answers to these.
Offline
ffp and optware are two small projects designed to add functionality to some existing base system (the big one is pkgsrc, www.pkgsrc.se). They differ in certain design choices and tools.
Some of your questions have been asked before, see e.g. http://dns323.kood.org/forum/viewtopic.php?id=2385
why these distributions do not compile against the uClibc that is provided natively
optware does compile against the native libc. And so did ffp up to version 0.4. Since 0.5 ffp ships its own libc, which allows it to run unmodified on at least 10 different devices (see wiki for the list), while you need different versions of optware. Further, optware reuses the manufacturers toolchain while ffp has it's own set of tools. E.g., this allows ffp to use more recent tools and the faster software-floating point approach on the dns-323.
It looks like the ffp distributed code is very picky about making sure that it picks up its libraries from /ffp/lib. What is the reason for that?
At least for packages that can be compiled that way, it seems like there would be some advantage to compiling against the uClibc that is provided natively since that would optimize memory use, paging, ...
I don't think the memory question is really relevant. optware installs it's own libraries, too, except that they have chosen to leave out one specific lib: libc. uClibc is designed to be small, so the extra cost in ffp is not large. Moreover, compared to the firmware libc, ffp's libc has lots of bugs fixed, and additional features.
ffp is picky about library paths since 19 Apr 2008 ( see http://www.inreto.de/dns323/fun-plug/0.5/ChangeLog.txt ). There was a CH3SNAS firmware version that did set LD_LIBRARY_PATH to /usr/lib. This made ffp try to use firmware libraries that were not fully compatible.
Offline
Fonz,
Thanks for the complete reply!
I'll check out the threads you mention.
Offline