Re: NetBSD on embedded devices

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Jun 04, 2017 at 08:16:16PM +0200, Emmanuel Dreyfus wrote:
> Thor Lancelot Simon <tls%panix.com@localhost> 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