Summary: experiences with NanoBSD,
successes and nits on a Soekris 4801
Sam Leffler
sam at errno.com
Fri Jul 1 18:12:40 GMT 2005
Poul-Henning Kamp wrote:
> In message <20050620.125334.10575355.imp at bsdimp.com>, "M. Warner Losh" writes:
>
>
>>The big problem is that there's not a build environment separate from
>>the install environment.
>
>
> I'm not 100% sure I know what you mean here...
>
>
>>At work, we created a system that has this
>>separation, and it has proven invaluable. The current NO_FOO knobs
>>aren't useful in the BUILD phase, bare are moderately useful in the
>>install phase (we actually go a step further, and just have a list of
>>directories to do an install from).
>>
>>This is the single reason that I've not pushed to migrate our build
>>system at work to using nanobsd as its base...
>
>
> It's worth noting in this context that not even "make release" uses
> an unadultered installworld, but instead has to use the pseudo-magic
> "distribution" target followed my manually frobbing the resulting
> tree.
>
> The biggest problem however is not the 'how' but the 'which' question.
>
> Take /usr/share/man/man1/gcc.1.gz as an example.
>
> That file should not be installed if the user has specified any
> single one of:
>
> NO_GNU # No GNU license code.
> NO_GCC # No GNU Compiler
> NO_CC # NO C compiler
> NO_TOOL_CHAIN # No compiler tools at all
> NO_MAN # No manual pages
> NO_CPP_RT # No C++ runtime
> NO_ROFF # No troff tools
> NO_GROFF # No GNU groff
> NO_MDOC # No mdoc macro package
>
> (NB: Deliberate exaggeration for illustrative effect)
>
> The src/release/Makefile is a good example of why Makefiles is not
> the right technology to implement conditional behaviour in this
> level of detail.
>
> The ideal solution would be to have complete awareness of the
> actual dependencies (as a combination of explicit entries and
> makefile derived information) but unless a exhaustive programme
> of tinderbox tests were instituted, the manually maintained
> dependencies would not be correct most of the time.
>
>
> And I will also echo the previously expressed sentiment that this
> is not to domain area to over-engineer a solution.
>
> Right now there is a $24 retail price difference between the smallest
> CF card I can buy (128M) and one that can contain a non-reduced
> nanobsd installation (512M). There are templates in the nanobsd
> sources for media sizes down to 64M for people to start from.
>
> I'm not saying that the problem is entirely solved, we are 90% of
> the way there now, and the last 10% may simply not be worth it.
>
>
Not to restart a thread that seems to have expired, but this attitude
that one can just buy a larger part is not helpful. Some devices have a
fixed flash size and you cannot simply replace them. For freebsd to be
truly useful in an embedded environment it must be configurable for any
size part. This usually means a packaging system where you specify what
to include rather than what to exclude. But it also means a lot of
other things like a kernel that can be well-tailored to needs (i.e. chop
all unnecessary bits). And then there's the whole issue of flash
filesystems. Needless to say we're a ways behind linux in this regard.
Sam
More information about the freebsd-current
mailing list