On Fri, Aug 6, 2010 at 11:57 AM, Dave Martin <dave.mar...@linaro.org> wrote:
> On Fri, Aug 6, 2010 at 9:53 AM, Alexander Sack <a...@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. -- - Alexander
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
