On Fri, Aug 6, 2010 at 11:57 AM, Dave Martin dave.martin@linaro.org wrote:
On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack asac@linaro.org wrote:>>
- stripping /usr/share/doc out (but everybody knew that)
ack. we plan to do that using pitti's dpkg improvements; last time they didn't land in the archive yet, but I will check the status soon again.
It's interesting to note that due to the fact that /usr/share/doc contains mostly nearly-empty directories and tiny files, the filesystem overhead may be a significant part of the overall consumption here - I estimate about 20-30% of the overall space, assuming a typical filesystem with 4KB blocksize.
If we have to keep /usr/share/doc/ (for copyright notices and so on), maybe it would be feasible to replace each /usr/share/doc/<package>/ with a tarball? This would eliminate most of the overhead as well as making the actual data smaller. Since /usr/share/doc/ is not accessed often, and not accessed by many automated tools, this might not cause much disruption.
CCed Martin who probably has thought about this copyright/space dilemma while implementing the dpkg goody i mentioned above.
[...]
- stripping out modules for devices that won't ever be on this ARM device
yeah, this feels to make sense. However, I am not sure how to draw the
line.
Maybe this is something the kernel WG can take a look at and come up with
a
reduced list of modules?
Classifying drivers by bus, and throwing out anything that can't be physically connected, such as PCI/AGP/ISA might be an approach here. Also, peripherals which can only be connected to on-SoC buses, but are not present in a given platform's silicon could be excluded. We would still have to keep a lot though... anything which can be connected via USB, for example.
Right. I had something like that in mind too and I think it's the safe way to go for our "standard" linaro kernels. I wonder if we need a process/policy that says what modules are needed to become an official "linaro" BSP kernel :).
Also, once we have support for hardware support packs vendors or people that want to create kernels etc. with even less modules could still do that on their own.
A more ambitious solution might be to allow for dynamic installation of missing modules, but that's probably a separate project since it would impact on the way the kernel is packaged.
Personal feeling on this is that we shouldn't go that far in linaro. But I would like to hear other opinions on this.