嵌入式Linux缩减问题

时间:2021-07-03 18:57:35
大家好,本人目前刚刚接触Linux。现在公司的项目需要缩减Linux的Kernel和APP部分的Code Size。目前我们使用的是Linux2.6.22.15版本,应用于ADSL Modem(家庭网关)。

1.我们产品应用是ADSL Gateway,Kernel部分裁剪工作已经差不多了,目前Kernel Flash Size大小为620KB左右,基于Linux 2.6.22.15.

2.目前我们使用的是Squash的只读的文件系统,从网络上了解的资料是目前压缩比最高的了。Rootfs压缩后的Flash Size为1.9MB左右

3.因为是Gateway,所以App有很多。像路由,DHCP,HTTP,SNMP,TR69,TR64,telnet,ftp等等。目前共有27个应用程序,压缩后的Flash
Size 840KB左右。

目前的任务就是从Kernel和Rootfs下手。把现在Kernel+rootfs=2.8M的体积要缩小到2M以内。功能部分不能减少,所以感觉难度很大。


App部分有一个想法,想参考BusyBox的做法,把所有的App都放到一个App中实现,然后用ln的方式导出每个App的链接,这样就可以缩掉好多link
symbol,库函数也可以用静态链接的方式去掉多余的库函数。请问一下这种方式来实现有没有可能?如果可以的话有没有什么缺陷?




目前系统各部分占用的Flash Size如下面所示:


项目           小类                       Flash Size(KB)     达到目标Size(KB)   目前实验能够达到Size(KB)
Kernel        Kernel(without ipv6)      800                 500                    630
Rootfs        Driver                      508                 300                    430
                 Application              832                 766                     ?
                 Lib(uclib,pthread..)  400                 250                     ?
                 GUI,configfile,others    124                 124
合计                                      2.664MB             1.94MB



请教一下大家有没有这方面的经验,上面初步估算达到目标Size有没有可能实现,谢谢!

100 个解决方案

#1


bang ding

#2


该回复于2009-10-11 08:58:05被版主删除

#3


App部分有一个想法,想参考BusyBox的做法,把所有的App都放到一个App中实现,然后用ln的方式导出每个App的链接,这样就可以缩掉好多link symbol,库函数也可以用静态链接的方式去掉多余的库函数。请问一下这种方式来实现有没有可能?如果可以的话有没有什么缺陷? 

-----------------
完全可行,只是在main函数处针对传入的argv[0]做一个分发罢了。

静态链接也是个好东西。

你的思路完全正确,我不认为有什么缺陷。

另外,你的CPU是什么?带FPU吗?需要FP计算吗?内核如何配置的?使用gcc还是专用的编译器?版本多少?优化选项是什么?

#4



另外,你的CPU是什么?带FPU吗?需要FP计算吗?内核如何配置的?使用gcc还是专用的编译器?版本多少?优化选项是什么?

--------------------------

CPU是MIPS架构的,没有FPU。使用的mips-linux-gcc编译器,版本还不清楚。编译时有带Os选项。

内核配置的Config文件太大,没法丢上去。请问你有没有MSN或者Skype。

#5


gcc版本是3.3.2

#6


为什么不直接用Busybox呢?

#7


rootfs还有没有变小的空间?

#8


Rootfs        Driver                      508                300                    430 


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。

#9


感谢大家的回复,目前我做的初步方案如下:

1.Kernel部分可以通过裁剪不需要的模块实现Shrink
2.Driver部分可以取消Module方式来实现Shrink(编入到Kernel中)
3.App中iptable可以通过结合目前我们的应用简化程序来实现Shrink
4.App部分有一个想法,想参考BusyBox的做法,把所有的App都放到一个App中实现

但是在这个基础上,还是满足不了需求。

对比了Broadcom BCM6338系列的ADSL Modem发现。Broadcom公司使用的Linux版本是2.6.8.1,该版本Kernel Size是470KB左右,比目前我们的要小330KB。rootfs部分的大小有1.4MB,比我们的小500KB.

现在Kernel部分已经无法裁剪进行Shrink了,目前的难点和重点就放到App部分了。

#10


引用 8 楼 pottichu 的回复:
Rootfs        Driver                      508                300                    430


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


目前缩减的方案已经将Driver放到Kernel中去了,请问还有其他的方案吗,谢谢!

#11


引用 7 楼 jiazhen 的回复:
为什么不直接用Busybox呢?
rootfs还有没有变小的空间?


已经使用BusyBox了。rootfs变小的空间只有从Application程序入手了,目前的想法就是参考BusyBox的做法,把所有程序放到一个程序里面。

#12


差不多了, kernel好像用了network就有7,8K的样子。
app都strip了吗?

#13


引用 12 楼 showman 的回复:
差不多了, kernel好像用了network就有7,8K的样子。
app都strip了吗?


App都用了Strip了。所以缩减这部分的难度很大。

#14


引用 8 楼 pottichu 的回复:
Rootfs        Driver                      508                300                    430


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?

#15


不知道你是什么平台,可以把code段放到flash上,这样可以省很多内存
还有,app的内存可以分类型的减小,stack的内存可以适当的减小buffersize,heap的内存可以看是不是malloc太大了,逐个应用去减,能减很多的,还有,rodata可以放到flash上去

#16


引用 14 楼 win847 的回复:
引用 8 楼 pottichu 的回复:
Rootfs        Driver                      508                300                    430


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?


用脚趾头也能算出来啊,用Module的方式加载的时候会需要内存啊,内核需要维护一个链表。

#17


引用 15 楼 cdbdyx 的回复:
不知道你是什么平台,可以把code段放到flash上,这样可以省很多内存
还有,app的内存可以分类型的减小,stack的内存可以适当的减小buffersize,heap的内存可以看是不是malloc太大了,逐个应用去减,能减很多的,还有,rodata可以放到flash上去


我的目标就是缩减存储在Flash的Kernel+rootfs大小,而不是App RAM的大小。

请问你有没有关于缩减Linux Code大小的一些经验呢?

#18


引用 16 楼 cdbdyx 的回复:
引用 14 楼 win847 的回复:
引用 8 楼 pottichu 的回复:
Rootfs        Driver                      508                300                    430


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?


用脚趾头也能算出来啊,用Module的方式加载的时候会需要内存啊,内核需要维护一个链表。


我的意思是Flash大小变小了,而不是占用RAM大小变小了。

就是说Kernel+Driver Module的Flash Size > Kernel(包含Driver)的Flash Size


#19


路过打酱油!

#20


mark

#21


luguo

#22


引用 17 楼 win847 的回复:
引用 15 楼 cdbdyx 的回复:
不知道你是什么平台,可以把code段放到flash上,这样可以省很多内存
还有,app的内存可以分类型的减小,stack的内存可以适当的减小buffersize,heap的内存可以看是不是malloc太大了,逐个应用去减,能减很多的,还有,rodata可以放到flash上去


我的目标就是缩减存储在Flash的Kernel+rootfs大小,而不是App RAM的大小。

请问你有没有关于缩减Linux Code大小的一些经验呢?


flash还至于这么省啊。。。。如果kernel不是压缩的可以压缩一下先
kernel的裁剪无非就是先通过配置把不用的都剪掉,然后再根据具体的需要,看kernel的代码了,不过不是对内核特别了解的话会比较难,而且会有稳定性的问题。

#23


ddddddddd

#24


学习了,谢谢!

#25


顶!!

#26


不是太懂,不过很喜欢研究这个东西,顶顶!

#27


谢谢大家的回复,为了提高竞争力。所以会尽量压缩体积,使得能够放在2M的Flash上面。

目前Kernel和rootfs都是经过压缩的,单纯从压缩工具上讲已经没有可以压缩的空间了。所以现在要在kernel和rootfs的相关Module和Application上想办法来进行缩减工作

#28


xue xi

#29


引用 18 楼 win847 的回复:
引用 16 楼 cdbdyx 的回复:
 引用 14 楼 win847 的回复:
 引用 8 楼 pottichu 的回复:
 Rootfs        Driver                      508                300                    430


 Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


 请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?


 用脚趾头也能算出来啊,用Module的方式加载的时候会需要内存啊,内核需要维护一个链表。


 我的意思是Flash大小变小了,而不是占用RAM大小变小了。

 就是说Kernel+Driver Module的Flash Size > Kernel(包含Driver)的Flash Size


帮顶,我也有这个疑问

#30


支持 一下 

#31


引用 27 楼 win847 的回复:
谢谢大家的回复,为了提高竞争力。所以会尽量压缩体积,使得能够放在2M的Flash上面。

 目前Kernel和rootfs都是经过压缩的,单纯从压缩工具上讲已经没有可以压缩的空间了。所以现在要在kernel和rootfs的相关Module和Application上想办法来进行缩减工作


你们的文件系统是怎么压缩的? 另外,你们的内存有多大?

#32


引用 14 楼 win847 的回复:
引用 8 楼 pottichu 的回复:
 Rootfs        Driver                      508                300                    430


 Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


 请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?


这个主要是经验之谈,编译成模块方式的时候 ko 文件中包含了很多其他的信息比如:
modinfo  xxx.ko 所看到的信息。

#33


也太追求成本了,flash有必要很小吗?

#34


引用 31 楼 pottichu 的回复:
引用 27 楼 win847 的回复:
谢谢大家的回复,为了提高竞争力。所以会尽量压缩体积,使得能够放在2M的Flash上面。

目前Kernel和rootfs都是经过压缩的,单纯从压缩工具上讲已经没有可以压缩的空间了。所以现在要在kernel和rootfs的相关Module和Application上想办法来进行缩减工作


你们的文件系统是怎么压缩的? 另外,你们的内存有多大?


我们的文件系统是Squash LZMA压缩的。内存是16M,要求最好要能在8M运行

#35


建议用RTOS吧,这个大小都按字节算的,App用开源的移植一下。1M以内都没问题....

#36


引用 34 楼 win847 的回复:
 我们的文件系统是Squash LZMA压缩的。内存是16M,要求最好要能在8M运行


Squash LZMA 的压缩比貌似已经是最佳的压缩了,这方面应该没办法更小了。

#37


引用 35 楼 dotmonkey 的回复:
建议用RTOS吧,这个大小都按字节算的,App用开源的移植一下。1M以内都没问题....


目前移植的平台早就定好了,是基于Linux2.6.22.15的,不可能重新移植一遍

#38


该回复于2009-10-13 17:09:38被版主删除

#39


RTOS是一个可行的方案,建议试一试

#40


要参照busybox把所有的app做成一个可执行程序是非常不好的办法。

最好的办法是寻找最合适的app 版本, 建议用最稳定的老版本,不要尝鲜。比如busybox1.0有时候就已经满足所有的要求了, 还有就是ftp, telnet尽量用busybox的。

其它的app也采用同样的方法。

还有就是libc方面,看看哪个可以不用。或者也使用较低版本,能满足要求就行。

到底要节省内存还是flash空间要有一个均衡的选择,如果所有app做成一个可执行程序(还要考虑修改编译的复杂性),flash空间是少了,内存空间呢?

常用的app最好用单独程序,如busybox的init这些常驻内存的要单独编译才合适

#41


引用 39 楼 renas01as01 的回复:
RTOS是一个可行的方案,建议试一试


请问RTOS是指什么,能否说详细一点??

#42


引用 40 楼 garibaldi 的回复:
要参照busybox把所有的app做成一个可执行程序是非常不好的办法。

最好的办法是寻找最合适的app 版本, 建议用最稳定的老版本,不要尝鲜。比如busybox1.0有时候就已经满足所有的要求了, 还有就是ftp, telnet尽量用busybox的。

其它的app也采用同样的方法。

还有就是libc方面,看看哪个可以不用。或者也使用较低版本,能满足要求就行。

到底要节省内存还是flash空间要有一个均衡的选择,如果所有app做成一个可执行程序(还要考虑修改编译的复杂性),flash空间是少了,内存空间呢?

常用的app最好用单独程序,如busybox的init这些常驻内存的要单独编译才合适


目前主要考虑是flash的空间。

如果不考虑把所有的App放到一个里面,这样的话就要考虑Lib库裁剪的问题,lib库的裁剪难度也会是很大的?

#43


增加一块flash比加一块内存的成本会贵多少?
硬件方面有“摩尔定律”,
就是了节省不到一M的flash空间,牺牲产品的稳定性,增加了开发难度,一点都不值得。

照你上面所说,你现在所做的就放在了app上面,都采用了哪些开源,哪个版本?列出来让大家看看先。

另外你的列表中所说的所占的flash是压缩之后的?压缩之后的uclibc有400k?

#44


引用 43 楼 garibaldi 的回复:
增加一块flash比加一块内存的成本会贵多少?
硬件方面有“摩尔定律”,
就是了节省不到一M的flash空间,牺牲产品的稳定性,增加了开发难度,一点都不值得。

照你上面所说,你现在所做的就放在了app上面,都采用了哪些开源,哪个版本?列出来让大家看看先。

另外你的列表中所说的所占的flash是压缩之后的?压缩之后的uclibc有400k?


目前我们的App都使用的开源的,主要占空间的App如下:

App名         版本      FlashSize  注释
busybox      1.0      144
iptables     1.3.8    196
pppd         2.4.1    72
bftpd                 16
boa                   36
dhcrelay              16   dhcp relay功能
Ez-ipupdate  3.0.0    20    DDNS功能
ripd         0.93a    32    与下面的Zebra是同一个版本
snmpd        5.3.1    112   net-snmp-5.3.1
upnpd                 20
zebra        0.93a    32    


Lib库包含uclibc,pthread,xml,libebtable(ebtable相关的)这几个。整个加起来RAM Size是5.7MB,压缩后的Flash Size是400KB左右


#45


增加RAM Size这列,请大家参考一下,看各个App有多大缩减的可能,谢谢!

目前我们的App都使用的开源的,主要占空间的App如下: 

App名        版本      FlashSize(KB)  RAMSize(KB)       注释 
busybox      1.0      144            514
iptables    1.3.8     196            627
pppd        2.4.1     72             261
bftpd                 16             70
boa                   36             135.3         HTTP Server
dhcrelay              16             67             dhcp relay功能 
Ez-ipupdate  3.0.0    20             86             DDNS功能 
ripd         0.93a    32             122             与下面的Zebra是同一个版本 
snmpd        5.3.1    112            418             net-snmp-5.3.1 
upnpd                 20             65
zebra        0.93a    32             112


Lib库包含uclibc,pthread,xml,libebtable(ebtable相关的)这几个。整个加起来RAM Size是5.7MB,压缩后的Flash Size是400KB左右 

#46


目前系统中使用的所有Lib库的RAM Size大小如下所示:

                                          RAM Size

-rwxr-xr-x    1 0        1500        25592 ld-uClibc-0.9.29.so
lrwxrwxrwx    1 0        1500           14 ld-uClibc.so -> ld-uClibc.so.0
lrwxrwxrwx    1 0        1500           19 ld-uClibc.so.0 -> ld-uClibc-0.9.29.so
lrwxrwxrwx    1 0        1500            9 libc.so -> libc.so.0
lrwxrwxrwx    1 0        1500           19 libc.so.0 -> libuClibc-0.9.29.so
-rw-r--r--    1 0        1500        14324 libcrypt-0.9.29.so
lrwxrwxrwx    1 0        1500           13 libcrypt.so -> libcrypt.so.0
lrwxrwxrwx    1 0        1500           18 libcrypt.so.0 -> libcrypt-0.9.29.so
-rw-r--r--    1 0        1500         9284 libdl-0.9.29.so
lrwxrwxrwx    1 0        1500           10 libdl.so -> libdl.so.0
lrwxrwxrwx    1 0        1500           15 libdl.so.0 -> libdl-0.9.29.so
-rwxr-xr-x    1 0        0            6792 libebt_802_3.so
-rwxr-xr-x    1 0        0           14316 libebt_among.so
-rwxr-xr-x    1 0        0           13674 libebt_arp.so
-rwxr-xr-x    1 0        0            6799 libebt_arpreply.so
-rwxr-xr-x    1 0        0            5298 libebt_ftos.so
-rwxr-xr-x    1 0        0           17686 libebt_ip.so
-rwxr-xr-x    1 0        0            8473 libebt_limit.so
-rwxr-xr-x    1 0        0            8086 libebt_log.so
-rwxr-xr-x    1 0        0            7602 libebt_mark.so
-rwxr-xr-x    1 0        0            5707 libebt_mark_m.so
-rwxr-xr-x    1 0        0            9351 libebt_nat.so
-rwxr-xr-x    1 0        0            6097 libebt_pkttype.so
-rwxr-xr-x    1 0        0            5460 libebt_redirect.so
-rwxr-xr-x    1 0        0            4538 libebt_standard.so
-rwxr-xr-x    1 0        0           13438 libebt_stp.so
-rwxr-xr-x    1 0        0            8237 libebt_ulog.so
-rwxr-xr-x    1 0        0           10654 libebt_vlan.so
-rwxr-xr-x    1 0        0            3214 libebtable_broute.so
-rwxr-xr-x    1 0        0            3326 libebtable_filter.so
-rwxr-xr-x    1 0        0            3323 libebtable_nat.so
-rwxr-xr-x    1 0        0          104252 libebtc.so
-rwxr-xr-x    1 0        1500        33724 libiw.so.28
-rw-r--r--    1 0        1500       144320 libm-0.9.29.so
lrwxrwxrwx    1 0        1500            9 libm.so -> libm.so.0
lrwxrwxrwx    1 0        1500           14 libm.so.0 -> libm-0.9.29.so
lrwxrwxrwx    1 572      1500           14 libmxml.so -> libmxml.so.1.4
lrwxrwxrwx    1 572      1500           14 libmxml.so.1 -> libmxml.so.1.4
-rwxr-xr-x    1 572      1500        34956 libmxml.so.1.4
-rw-r--r--    1 0        1500         2216 libnsl-0.9.29.so
lrwxrwxrwx    1 0        1500           11 libnsl.so -> libnsl.so.0
lrwxrwxrwx    1 0        1500           16 libnsl.so.0 -> libnsl-0.9.29.so
-rwxr-xr-x    1 572      1500        11692 libpppoatm.so
-rwxr-xr-x    1 572      1500        36692 libpppoe.so
-rw-r--r--    1 0        1500       338456 libpthread-0.9.29.so
lrwxrwxrwx    1 0        1500           15 libpthread.so -> libpthread.so.0
lrwxrwxrwx    1 0        1500           20 libpthread.so.0 -> libpthread-0.9.29.so
-rw-r--r--    1 0        1500         2236 libresolv-0.9.29.so
lrwxrwxrwx    1 0        1500           14 libresolv.so -> libresolv.so.0
lrwxrwxrwx    1 0        1500           19 libresolv.so.0 -> libresolv-0.9.29.so
-rw-r--r--    1 0        1500         5188 librt-0.9.29.so
lrwxrwxrwx    1 0        1500           10 librt.so -> librt.so.0
lrwxrwxrwx    1 0        1500           15 librt.so.0 -> librt-0.9.29.so
lrwxrwxrwx    1 572      1500           15 libtcapi.so -> libtcapi.so.1.4
lrwxrwxrwx    1 572      1500           15 libtcapi.so.1 -> libtcapi.so.1.4
-rwxr-xr-x    1 572      1500         7292 libtcapi.so.1.4
-rw-r--r--    1 0        1500       770416 libuClibc-0.9.29.so
lrwxrwxrwx    1 0        1500           14 libuClibc.so -> libuClibc.so.0
lrwxrwxrwx    1 0        1500           19 libuClibc.so.0 -> libuClibc-0.9.29.so
-rw-r--r--    1 0        1500         5620 libutil-0.9.29.so
lrwxrwxrwx    1 0        1500           12 libutil.so -> libutil.so.0
lrwxrwxrwx    1 0        1500           17 libutil.so.0 -> libutil-0.9.29.so

#47


kernel, busybox, uclibc的config文件传一份?

你的app里,除了net-snmp, busybox外,其它的都还可以,uclibc似乎大了点,有没有可能除掉一部分呢?

#48


引用 47 楼 garibaldi 的回复:
kernel, busybox, uclibc的config文件传一份?

你的app里,除了net-snmp, busybox外,其它的都还可以,uclibc似乎大了点,有没有可能除掉一部分呢?


uclibc目前的Src Code和Config文件没有

Kernel和Busybox的有,请问怎么样给你。我的Skype是win847, MSN是win847@hotmail.com

你可以加我,我传给你。谢谢!

#49


引用 47 楼 garibaldi 的回复:
kernel, busybox, uclibc的config文件传一份?

你的app里,除了net-snmp, busybox外,其它的都还可以,uclibc似乎大了点,有没有可能除掉一部分呢?


BusybBox确实还有裁剪的空间。上次初步实验可以把Flash Size缩到100KB左右。

#50


学习

#1


bang ding

#2


该回复于2009-10-11 08:58:05被版主删除

#3


App部分有一个想法,想参考BusyBox的做法,把所有的App都放到一个App中实现,然后用ln的方式导出每个App的链接,这样就可以缩掉好多link symbol,库函数也可以用静态链接的方式去掉多余的库函数。请问一下这种方式来实现有没有可能?如果可以的话有没有什么缺陷? 

-----------------
完全可行,只是在main函数处针对传入的argv[0]做一个分发罢了。

静态链接也是个好东西。

你的思路完全正确,我不认为有什么缺陷。

另外,你的CPU是什么?带FPU吗?需要FP计算吗?内核如何配置的?使用gcc还是专用的编译器?版本多少?优化选项是什么?

#4



另外,你的CPU是什么?带FPU吗?需要FP计算吗?内核如何配置的?使用gcc还是专用的编译器?版本多少?优化选项是什么?

--------------------------

CPU是MIPS架构的,没有FPU。使用的mips-linux-gcc编译器,版本还不清楚。编译时有带Os选项。

内核配置的Config文件太大,没法丢上去。请问你有没有MSN或者Skype。

#5


gcc版本是3.3.2

#6


为什么不直接用Busybox呢?

#7


rootfs还有没有变小的空间?

#8


Rootfs        Driver                      508                300                    430 


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。

#9


感谢大家的回复,目前我做的初步方案如下:

1.Kernel部分可以通过裁剪不需要的模块实现Shrink
2.Driver部分可以取消Module方式来实现Shrink(编入到Kernel中)
3.App中iptable可以通过结合目前我们的应用简化程序来实现Shrink
4.App部分有一个想法,想参考BusyBox的做法,把所有的App都放到一个App中实现

但是在这个基础上,还是满足不了需求。

对比了Broadcom BCM6338系列的ADSL Modem发现。Broadcom公司使用的Linux版本是2.6.8.1,该版本Kernel Size是470KB左右,比目前我们的要小330KB。rootfs部分的大小有1.4MB,比我们的小500KB.

现在Kernel部分已经无法裁剪进行Shrink了,目前的难点和重点就放到App部分了。

#10


引用 8 楼 pottichu 的回复:
Rootfs        Driver                      508                300                    430


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


目前缩减的方案已经将Driver放到Kernel中去了,请问还有其他的方案吗,谢谢!

#11


引用 7 楼 jiazhen 的回复:
为什么不直接用Busybox呢?
rootfs还有没有变小的空间?


已经使用BusyBox了。rootfs变小的空间只有从Application程序入手了,目前的想法就是参考BusyBox的做法,把所有程序放到一个程序里面。

#12


差不多了, kernel好像用了network就有7,8K的样子。
app都strip了吗?

#13


引用 12 楼 showman 的回复:
差不多了, kernel好像用了network就有7,8K的样子。
app都strip了吗?


App都用了Strip了。所以缩减这部分的难度很大。

#14


引用 8 楼 pottichu 的回复:
Rootfs        Driver                      508                300                    430


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?

#15


不知道你是什么平台,可以把code段放到flash上,这样可以省很多内存
还有,app的内存可以分类型的减小,stack的内存可以适当的减小buffersize,heap的内存可以看是不是malloc太大了,逐个应用去减,能减很多的,还有,rodata可以放到flash上去

#16


引用 14 楼 win847 的回复:
引用 8 楼 pottichu 的回复:
Rootfs        Driver                      508                300                    430


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?


用脚趾头也能算出来啊,用Module的方式加载的时候会需要内存啊,内核需要维护一个链表。

#17


引用 15 楼 cdbdyx 的回复:
不知道你是什么平台,可以把code段放到flash上,这样可以省很多内存
还有,app的内存可以分类型的减小,stack的内存可以适当的减小buffersize,heap的内存可以看是不是malloc太大了,逐个应用去减,能减很多的,还有,rodata可以放到flash上去


我的目标就是缩减存储在Flash的Kernel+rootfs大小,而不是App RAM的大小。

请问你有没有关于缩减Linux Code大小的一些经验呢?

#18


引用 16 楼 cdbdyx 的回复:
引用 14 楼 win847 的回复:
引用 8 楼 pottichu 的回复:
Rootfs        Driver                      508                300                    430


Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?


用脚趾头也能算出来啊,用Module的方式加载的时候会需要内存啊,内核需要维护一个链表。


我的意思是Flash大小变小了,而不是占用RAM大小变小了。

就是说Kernel+Driver Module的Flash Size > Kernel(包含Driver)的Flash Size


#19


路过打酱油!

#20


mark

#21


luguo

#22


引用 17 楼 win847 的回复:
引用 15 楼 cdbdyx 的回复:
不知道你是什么平台,可以把code段放到flash上,这样可以省很多内存
还有,app的内存可以分类型的减小,stack的内存可以适当的减小buffersize,heap的内存可以看是不是malloc太大了,逐个应用去减,能减很多的,还有,rodata可以放到flash上去


我的目标就是缩减存储在Flash的Kernel+rootfs大小,而不是App RAM的大小。

请问你有没有关于缩减Linux Code大小的一些经验呢?


flash还至于这么省啊。。。。如果kernel不是压缩的可以压缩一下先
kernel的裁剪无非就是先通过配置把不用的都剪掉,然后再根据具体的需要,看kernel的代码了,不过不是对内核特别了解的话会比较难,而且会有稳定性的问题。

#23


ddddddddd

#24


学习了,谢谢!

#25


顶!!

#26


不是太懂,不过很喜欢研究这个东西,顶顶!

#27


谢谢大家的回复,为了提高竞争力。所以会尽量压缩体积,使得能够放在2M的Flash上面。

目前Kernel和rootfs都是经过压缩的,单纯从压缩工具上讲已经没有可以压缩的空间了。所以现在要在kernel和rootfs的相关Module和Application上想办法来进行缩减工作

#28


xue xi

#29


引用 18 楼 win847 的回复:
引用 16 楼 cdbdyx 的回复:
 引用 14 楼 win847 的回复:
 引用 8 楼 pottichu 的回复:
 Rootfs        Driver                      508                300                    430


 Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


 请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?


 用脚趾头也能算出来啊,用Module的方式加载的时候会需要内存啊,内核需要维护一个链表。


 我的意思是Flash大小变小了,而不是占用RAM大小变小了。

 就是说Kernel+Driver Module的Flash Size > Kernel(包含Driver)的Flash Size


帮顶,我也有这个疑问

#30


支持 一下 

#31


引用 27 楼 win847 的回复:
谢谢大家的回复,为了提高竞争力。所以会尽量压缩体积,使得能够放在2M的Flash上面。

 目前Kernel和rootfs都是经过压缩的,单纯从压缩工具上讲已经没有可以压缩的空间了。所以现在要在kernel和rootfs的相关Module和Application上想办法来进行缩减工作


你们的文件系统是怎么压缩的? 另外,你们的内存有多大?

#32


引用 14 楼 win847 的回复:
引用 8 楼 pottichu 的回复:
 Rootfs        Driver                      508                300                    430


 Driver 为什么不直接编译到内核中去,可以节省不少空间阿。


 请问下使用编译进内核的方式为什么比Module的方式节省空间呢,有没有这方面的知识呢?


这个主要是经验之谈,编译成模块方式的时候 ko 文件中包含了很多其他的信息比如:
modinfo  xxx.ko 所看到的信息。

#33


也太追求成本了,flash有必要很小吗?

#34


引用 31 楼 pottichu 的回复:
引用 27 楼 win847 的回复:
谢谢大家的回复,为了提高竞争力。所以会尽量压缩体积,使得能够放在2M的Flash上面。

目前Kernel和rootfs都是经过压缩的,单纯从压缩工具上讲已经没有可以压缩的空间了。所以现在要在kernel和rootfs的相关Module和Application上想办法来进行缩减工作


你们的文件系统是怎么压缩的? 另外,你们的内存有多大?


我们的文件系统是Squash LZMA压缩的。内存是16M,要求最好要能在8M运行

#35


建议用RTOS吧,这个大小都按字节算的,App用开源的移植一下。1M以内都没问题....

#36


引用 34 楼 win847 的回复:
 我们的文件系统是Squash LZMA压缩的。内存是16M,要求最好要能在8M运行


Squash LZMA 的压缩比貌似已经是最佳的压缩了,这方面应该没办法更小了。

#37


引用 35 楼 dotmonkey 的回复:
建议用RTOS吧,这个大小都按字节算的,App用开源的移植一下。1M以内都没问题....


目前移植的平台早就定好了,是基于Linux2.6.22.15的,不可能重新移植一遍

#38


该回复于2009-10-13 17:09:38被版主删除

#39


RTOS是一个可行的方案,建议试一试

#40


要参照busybox把所有的app做成一个可执行程序是非常不好的办法。

最好的办法是寻找最合适的app 版本, 建议用最稳定的老版本,不要尝鲜。比如busybox1.0有时候就已经满足所有的要求了, 还有就是ftp, telnet尽量用busybox的。

其它的app也采用同样的方法。

还有就是libc方面,看看哪个可以不用。或者也使用较低版本,能满足要求就行。

到底要节省内存还是flash空间要有一个均衡的选择,如果所有app做成一个可执行程序(还要考虑修改编译的复杂性),flash空间是少了,内存空间呢?

常用的app最好用单独程序,如busybox的init这些常驻内存的要单独编译才合适

#41


引用 39 楼 renas01as01 的回复:
RTOS是一个可行的方案,建议试一试


请问RTOS是指什么,能否说详细一点??

#42


引用 40 楼 garibaldi 的回复:
要参照busybox把所有的app做成一个可执行程序是非常不好的办法。

最好的办法是寻找最合适的app 版本, 建议用最稳定的老版本,不要尝鲜。比如busybox1.0有时候就已经满足所有的要求了, 还有就是ftp, telnet尽量用busybox的。

其它的app也采用同样的方法。

还有就是libc方面,看看哪个可以不用。或者也使用较低版本,能满足要求就行。

到底要节省内存还是flash空间要有一个均衡的选择,如果所有app做成一个可执行程序(还要考虑修改编译的复杂性),flash空间是少了,内存空间呢?

常用的app最好用单独程序,如busybox的init这些常驻内存的要单独编译才合适


目前主要考虑是flash的空间。

如果不考虑把所有的App放到一个里面,这样的话就要考虑Lib库裁剪的问题,lib库的裁剪难度也会是很大的?

#43


增加一块flash比加一块内存的成本会贵多少?
硬件方面有“摩尔定律”,
就是了节省不到一M的flash空间,牺牲产品的稳定性,增加了开发难度,一点都不值得。

照你上面所说,你现在所做的就放在了app上面,都采用了哪些开源,哪个版本?列出来让大家看看先。

另外你的列表中所说的所占的flash是压缩之后的?压缩之后的uclibc有400k?

#44


引用 43 楼 garibaldi 的回复:
增加一块flash比加一块内存的成本会贵多少?
硬件方面有“摩尔定律”,
就是了节省不到一M的flash空间,牺牲产品的稳定性,增加了开发难度,一点都不值得。

照你上面所说,你现在所做的就放在了app上面,都采用了哪些开源,哪个版本?列出来让大家看看先。

另外你的列表中所说的所占的flash是压缩之后的?压缩之后的uclibc有400k?


目前我们的App都使用的开源的,主要占空间的App如下:

App名         版本      FlashSize  注释
busybox      1.0      144
iptables     1.3.8    196
pppd         2.4.1    72
bftpd                 16
boa                   36
dhcrelay              16   dhcp relay功能
Ez-ipupdate  3.0.0    20    DDNS功能
ripd         0.93a    32    与下面的Zebra是同一个版本
snmpd        5.3.1    112   net-snmp-5.3.1
upnpd                 20
zebra        0.93a    32    


Lib库包含uclibc,pthread,xml,libebtable(ebtable相关的)这几个。整个加起来RAM Size是5.7MB,压缩后的Flash Size是400KB左右


#45


增加RAM Size这列,请大家参考一下,看各个App有多大缩减的可能,谢谢!

目前我们的App都使用的开源的,主要占空间的App如下: 

App名        版本      FlashSize(KB)  RAMSize(KB)       注释 
busybox      1.0      144            514
iptables    1.3.8     196            627
pppd        2.4.1     72             261
bftpd                 16             70
boa                   36             135.3         HTTP Server
dhcrelay              16             67             dhcp relay功能 
Ez-ipupdate  3.0.0    20             86             DDNS功能 
ripd         0.93a    32             122             与下面的Zebra是同一个版本 
snmpd        5.3.1    112            418             net-snmp-5.3.1 
upnpd                 20             65
zebra        0.93a    32             112


Lib库包含uclibc,pthread,xml,libebtable(ebtable相关的)这几个。整个加起来RAM Size是5.7MB,压缩后的Flash Size是400KB左右 

#46


目前系统中使用的所有Lib库的RAM Size大小如下所示:

                                          RAM Size

-rwxr-xr-x    1 0        1500        25592 ld-uClibc-0.9.29.so
lrwxrwxrwx    1 0        1500           14 ld-uClibc.so -> ld-uClibc.so.0
lrwxrwxrwx    1 0        1500           19 ld-uClibc.so.0 -> ld-uClibc-0.9.29.so
lrwxrwxrwx    1 0        1500            9 libc.so -> libc.so.0
lrwxrwxrwx    1 0        1500           19 libc.so.0 -> libuClibc-0.9.29.so
-rw-r--r--    1 0        1500        14324 libcrypt-0.9.29.so
lrwxrwxrwx    1 0        1500           13 libcrypt.so -> libcrypt.so.0
lrwxrwxrwx    1 0        1500           18 libcrypt.so.0 -> libcrypt-0.9.29.so
-rw-r--r--    1 0        1500         9284 libdl-0.9.29.so
lrwxrwxrwx    1 0        1500           10 libdl.so -> libdl.so.0
lrwxrwxrwx    1 0        1500           15 libdl.so.0 -> libdl-0.9.29.so
-rwxr-xr-x    1 0        0            6792 libebt_802_3.so
-rwxr-xr-x    1 0        0           14316 libebt_among.so
-rwxr-xr-x    1 0        0           13674 libebt_arp.so
-rwxr-xr-x    1 0        0            6799 libebt_arpreply.so
-rwxr-xr-x    1 0        0            5298 libebt_ftos.so
-rwxr-xr-x    1 0        0           17686 libebt_ip.so
-rwxr-xr-x    1 0        0            8473 libebt_limit.so
-rwxr-xr-x    1 0        0            8086 libebt_log.so
-rwxr-xr-x    1 0        0            7602 libebt_mark.so
-rwxr-xr-x    1 0        0            5707 libebt_mark_m.so
-rwxr-xr-x    1 0        0            9351 libebt_nat.so
-rwxr-xr-x    1 0        0            6097 libebt_pkttype.so
-rwxr-xr-x    1 0        0            5460 libebt_redirect.so
-rwxr-xr-x    1 0        0            4538 libebt_standard.so
-rwxr-xr-x    1 0        0           13438 libebt_stp.so
-rwxr-xr-x    1 0        0            8237 libebt_ulog.so
-rwxr-xr-x    1 0        0           10654 libebt_vlan.so
-rwxr-xr-x    1 0        0            3214 libebtable_broute.so
-rwxr-xr-x    1 0        0            3326 libebtable_filter.so
-rwxr-xr-x    1 0        0            3323 libebtable_nat.so
-rwxr-xr-x    1 0        0          104252 libebtc.so
-rwxr-xr-x    1 0        1500        33724 libiw.so.28
-rw-r--r--    1 0        1500       144320 libm-0.9.29.so
lrwxrwxrwx    1 0        1500            9 libm.so -> libm.so.0
lrwxrwxrwx    1 0        1500           14 libm.so.0 -> libm-0.9.29.so
lrwxrwxrwx    1 572      1500           14 libmxml.so -> libmxml.so.1.4
lrwxrwxrwx    1 572      1500           14 libmxml.so.1 -> libmxml.so.1.4
-rwxr-xr-x    1 572      1500        34956 libmxml.so.1.4
-rw-r--r--    1 0        1500         2216 libnsl-0.9.29.so
lrwxrwxrwx    1 0        1500           11 libnsl.so -> libnsl.so.0
lrwxrwxrwx    1 0        1500           16 libnsl.so.0 -> libnsl-0.9.29.so
-rwxr-xr-x    1 572      1500        11692 libpppoatm.so
-rwxr-xr-x    1 572      1500        36692 libpppoe.so
-rw-r--r--    1 0        1500       338456 libpthread-0.9.29.so
lrwxrwxrwx    1 0        1500           15 libpthread.so -> libpthread.so.0
lrwxrwxrwx    1 0        1500           20 libpthread.so.0 -> libpthread-0.9.29.so
-rw-r--r--    1 0        1500         2236 libresolv-0.9.29.so
lrwxrwxrwx    1 0        1500           14 libresolv.so -> libresolv.so.0
lrwxrwxrwx    1 0        1500           19 libresolv.so.0 -> libresolv-0.9.29.so
-rw-r--r--    1 0        1500         5188 librt-0.9.29.so
lrwxrwxrwx    1 0        1500           10 librt.so -> librt.so.0
lrwxrwxrwx    1 0        1500           15 librt.so.0 -> librt-0.9.29.so
lrwxrwxrwx    1 572      1500           15 libtcapi.so -> libtcapi.so.1.4
lrwxrwxrwx    1 572      1500           15 libtcapi.so.1 -> libtcapi.so.1.4
-rwxr-xr-x    1 572      1500         7292 libtcapi.so.1.4
-rw-r--r--    1 0        1500       770416 libuClibc-0.9.29.so
lrwxrwxrwx    1 0        1500           14 libuClibc.so -> libuClibc.so.0
lrwxrwxrwx    1 0        1500           19 libuClibc.so.0 -> libuClibc-0.9.29.so
-rw-r--r--    1 0        1500         5620 libutil-0.9.29.so
lrwxrwxrwx    1 0        1500           12 libutil.so -> libutil.so.0
lrwxrwxrwx    1 0        1500           17 libutil.so.0 -> libutil-0.9.29.so

#47


kernel, busybox, uclibc的config文件传一份?

你的app里,除了net-snmp, busybox外,其它的都还可以,uclibc似乎大了点,有没有可能除掉一部分呢?

#48


引用 47 楼 garibaldi 的回复:
kernel, busybox, uclibc的config文件传一份?

你的app里,除了net-snmp, busybox外,其它的都还可以,uclibc似乎大了点,有没有可能除掉一部分呢?


uclibc目前的Src Code和Config文件没有

Kernel和Busybox的有,请问怎么样给你。我的Skype是win847, MSN是win847@hotmail.com

你可以加我,我传给你。谢谢!

#49


引用 47 楼 garibaldi 的回复:
kernel, busybox, uclibc的config文件传一份?

你的app里,除了net-snmp, busybox外,其它的都还可以,uclibc似乎大了点,有没有可能除掉一部分呢?


BusybBox确实还有裁剪的空间。上次初步实验可以把Flash Size缩到100KB左右。

#50


学习