tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BeastieBox, a (Net)BSD BusyBox-like
On Mon, 8 Dec 2008, Arnaud Lacombe wrote:
On Mon, Dec 8, 2008 at 5:58 PM, David Brownlee <abs%netbsd.org@localhost> wrote:
Thats not entirely a fair metric:
- My 4.4MB /rescue gzips down to 2.2MB, which means vndcompress(1)
could be a real win
This is a bogus reasoning. Architecture we are speaking about also
have RAM constraint and you can hardly vndcompress(1) md image
embedded in the kernel.
Thats a limitation in the current implementation. vnd(4)
has kernel support for compressed file images with
VND_COMPRESSION. md(4) should be updated to use the same
(de)compression code, at which point you *can* vndcompress(1)
md images embedded in the kernel. They would not be writable,
but we have mount_tmpfs or mount_mfs.
- None of the numbers I've quoted above were with -DSMALL, plus
Thor's previous comments about making -DSMALL work for libc and
others could gain a lot
Maybe the libc could be shrunken too. 170k for a static executable
which take 10k dynamically is defitively too much.
Absolutely. There is a lot going on in libc which could be
conditionalised out on -DSMALL
My gut feeling would be tuning the set of binaries and some
work with -DSMALL could get your 3.4MB down to 2.5MB
with a lot of #ifdef, certainly.
I'd love see a kernel + minimal usable userland fit in 4MB, at *runtime*.
Is that 4MB RAM + 4MB flash, or 4MB ram+flash together?
I would suggest adding the equivalent of VND_COMPRESSION
to md(4) would go a long way towards that, and a second
big win (for space if not performance) would be being able
to run the compressed filesystem image direct from flash.
Either of those are likely to give more benefit than any
amount of work on -DSMALL (Though that work would definitely
also help)
--
David/absolute -- www.NetBSD.org: No hype required --
Home |
Main Index |
Thread Index |
Old Index