On Sun, Jun 04, 2017 at 08:16:16PM +0200, Emmanuel Dreyfus wrote: > Thor Lancelot Simon <t...@panix.com> wrote: > > > One key idea that may help you is not mine -- it's due to Matt Thomas. It > > is > > the idea of, making an *additional* bunch of sets files specifying > > exactly and only the parts of the system you need. Then install those > > (embedbase.txt, embedetc.tgz, etc.) rather than base, etc, and so forth. > > That will give you a simple, maintainable way to build a NetBSD that > > does what you need, is still a coherent whole rather than a pile of > > disjoint "system packages", and is much smaller. > > One interesting feature is also to crunchgen(1) binaries to reduce > memory footprint, which is interesting when booting a kernel with > ramdisk. It works nicely, but is not documented very much.
It's extremely hard to debug, though, can't crunch some executables together without nasty hacks, and effectively disables some system security features. And it saves less space than it used to now that we have dynamically linked /. It's a good tool when you're in too much of a hurry to figure out just exactly what programs you need to get the job done, but I generally recommend against. As an example, late in the development of a product about 10 years ago I suddenly found that to fix a problem observed in customer beta units in the field, I needed a very small ramdisk kernel for a single-file one-shot upgrade. I managed to make a minimal setlist replacing our already-cut-down "base" and "etc" with about 30 files, that would fit in a ramdisk of a couple of MB, crunchgen not required. This was enough to run a single carefully written shellscript that fixed the installation problem with the systems in question. It took me about a day of experimentation to get it right, but it was pretty fun really, adjusting the shell script and the setlists for the right balance of maintainability vs. space. It wasn't particularly hard to do. That said, /rescue is worlds better than busybox and the way the crunchgen framework can be used to add a program here or there is pretty cool. It goes to show how excellent NetBSD is a base for any embedded product large enough to run _any_ kind of Unix -- much, much better than any of even the commercial Linux or QNX based starting points that claim to support this kind of thing. The only similar effort I know of really is JunOS; and though JunOS does many things we don't, they are largely in the realm of support for additional hardware or networking protocols; I think as a base for a new embedded system, we're better. And you can't beat the cross-compilation support for producing a clean, reproducible system in a simple and elegant way. Nobody else has that. Thor
