Might as well add:

- Support for MMU-less architectures (if they managed to merge uCLinux in
Linux 2.6, then it must be feasible :-)

-- 
Scott Telford. 

> -----Original Message-----
> From: tech-embed-owner@NetBSD.org 
> [mailto:tech-embed-owner@NetBSD.org] On Behalf Of Allen Briggs
> Sent: 05 June 2007 02:48
> To: tech-embed@netbsd.org
> Subject: Looking ahead
> 
> Hi folks,
> 
> I've appointed myself to collect thoughts about future directions
> for NetBSD in the embedded space.  At the moment, this is more in
> terms of a list of items with no priority assigned to any of them.
> 
> I'll also add that this covers a range of systems--from a small
> device that lives attached to a wall somewhere doing something
> basic like logging weather data or a NAS / wireless router appliance
> like the Linksys NSLU2 all the way up to a much larger router or
> NAS device or something else--so it covers a wide range of systems
> and some of these things will make sense for some areas, but not
> for others.
> 
> All that said, here's the list I've gathered so far...
> 
> * Flash support
>   - Support for NOR devices (CFI, et al.)
>   - Support for NAND devices
>   - Flash filesystem
>     . wear leveling
>     . makefs support
>   - Support for RedBoot's FIS "disklabel"
>   - Library support for environment variables (getenv, setenv, commit,
> 	devprop?)
> * Build-to-image support
>   - Easy inclusion of 3rd-party, cross-compiled apps
>   - Easy configuration for reduced-size builds
> * Power management (conserve power when idle / semi-idle)
>   - powertop-like functionality?
>     (IBM/Linux PowerTOP recently mentioned on /.)
> * Remote core dumps (via tftp? ssh? ESP?)
> * Remote console support (via ssh? ESP?)
> * Remote debugging (via firewire or ip? gdb w/ kdp?, ssh-to-ddb? esp?)
> * Boot with no userland (no user context-switching)
> * Remote gathering of profiling data (gprof at first?)
>   - Support for gathering data for Intel VTune (x86 / XScale)
>   - Revitalized support for PMCs
> * More efficient TCP/networking stack on lower-power hardware
> * Stable Kernel API
> * Support for layered security for LKMs (LKMs have no access to
> 	ring 0 on x86?)
> 
> I know that there are some efforts towards flash and build-to-image,
> or even some implementations out there right now, but until they're
> in the tree, they're "future".  ;-)
> 
> Anyone want to chime in with some other items?
> 
> Thanks,
> -allen
> 
> -- 
> Allen Briggs  |  http://www.ninthwonder.com/~briggs/  |  
> briggs@ninthwonder.com
> 
>