Re: Summary: experiences with NanoBSD, successes and nits on a Soekris 4801

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