Hi Folks following Andrew's suggestions I made a few tests with squashfs to see how an agreement on the presentation of data could be reached. I have not tested with the existing upgrade script, I just wanted to see what implications a squashfs based distribution of the modules tarball would have.
I built a kernel and busybox supporting squashfs and squashfs files for the modules directory. Installing these was pretty straightforward. I compared the sizes of the various forms of modules on the server side. The tarball and the squashfs have nearly the same size, whereas the unpacked modules directory is roughly 15% bigger. On systems with enough storage to accommodate the tarball installing the squashfs file is beneficial, as there is no space needed to unpack the tarball to. This allows even small systems to do successful autoprobing. On systems with insufficient storage for the modules squashfs but sufficient RAM it might be possible for processes like upgrade and hardware detection to download the squashfs to temporary storage and use it to install the necessary modules. On systems where both is impossible there is IMHO no way around granular access to modules. I believe though, that even a modest WRAP has sufficient RAM to support temporary storage of the squashfs, else these can be improved with a bigger CF card. This may be a pain for systems that have not been touched for years due to the cumbersome upgrade process, which I wanted to improve. There are a few drawbacks to the squashfs path and I don't want to neglect them. - tarballs can be used with a number of programs on various operating systems. I don't know if this is true for squashfs - the squashfs needs to be built just like the tarball, this needs a modification of the existing deployment scripts, which I have no clue what they are. - the existing scripts which use the tarballs all need to be adapted. My implementation of upgrade can probably be adapted, without an agreement on the access to the modules directory I will not move though. cheers 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
