Am 02.04.2015 um 16:27 schrieb Andrew:
02.04.2015 16:34, Erich Titl пишет:Hi AndrewAm 02.04.2015 um 12:35 schrieb Andrew:02.04.2015 13:16, Erich Titl пишет:Hi Andrew...Single tarball is easier for update than hundreds of small files.No it is not, if you have insufficient space. It is just a bloody pain in the butt. And then what is IT for if we cannot automate tasks. Maybe you have unlimited memory and storage on your target system, but this is not the 'normal' case.LEAF isn't targetted just for small systems. I use it on multicore servers - border/internal routers, BRAS servers... Also, hundreds of small files on local storage will consume more space than single tarball.Correct, but you have enough storage. I am not oposed to keep the tarballs, but automatic granular upgrades with little storage require granular file access.64-128M IDE DOM.
I have systems with 8-16 MB :-(
I stripped packages that aren't used on my systems.
So did I still no joy with modules.tgz :-) ...
..End user may change NIC for some enough rare that isn't in base moddb support. And he'll need to use module autoprobing feature in that case -There are systems where autoprobing fails, rare but true :-(Possibly due to limited RAM?so end user should have all modules on local storage. In compressed or in uncompressed form.Believe me, there are systems which don't have enough storage and for these we need a more granular aproach.From other side, we may do other trick: we may store modules in squashfs instead of tgz, and mount it instead of unpacking. And even we may remove moddb.lrp - just mount this squashfs at boot, probe modules, copy list of iptables-related modules + loaded modules into ram, and unmount module storage. This will save RAM on small systems, and simplify update handling :)How much more do you think you can compress the data? Let's assume you have about 20MB of storage available, can you meet that? I believe leaving away some of the modules depending on the target hardware might do the trick, but it leads us more individual target architectures. I for once believe that our geode package, geared most of the time towards ALIX systems (I looked in the geode config patch) has a heavy overload of modules which will never be used. On the other hand I am opposed to the idea of keeping unneeded, redundant code on a system for the rare case of a NIC change. Redundant for me are modules kept in more than _one_ of the following. -initmod.lrp -moddb.lrp -modules.tgzThere's 15MB modules.tgz size on fat i686 release. moddb.lrp - 2MB, but we should remove it if we'll have modules packed into squashfs (we don't need to place custom modules into system). initmod is relatively small (less than 1MB).
Still holds far too much which are not really used. We could try to remove them at the end of init.
Also IMHO we should remove lot of drivers from i486/geode (for ex., SCSI RAID controllers and so on - they are unneeded, a lot of NIC drivers - for ex., PCI-E cards drivers, and so on).
Yes ET
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
