Summary so far...

[Allen Briggs <briggs%netbsd.org@localhost>]

I've been trying to keep track of the various topics discussed so
far and a few more things that came to my mind while assembling
the notes.

Comments are, of course, still welcome.

-allen

---+ Embedded NetBSD

There are several classes of embedded systems that we look at here,
knowing that many devices may not fit neatly into each category:

   * Handheld/kiosk devices
      * Have more complex and interactive user interface than others
      * May have limited networking needs
      * Probably limited ROM / RAM resources

   * Dedicated control devices
      * May have a number of different sensors and "interesting" I/O
      * May have limited networking needs
      * Likely has no console and limited UI (maybe just power/reset,
        maybe a simple keypad / lcd)
      * Expected to run ~continuously

   * Network devices
      * Networking performance is important, but protocols may vary
      * UI probably web/net-based, but maybe CLI
      * These can range from home wireless base station / cable modem
        to large routers--obviously needs will vary.

   * Miscellaneous

As specifically noted under "Network devices," the size of these devices
will vary significantly and so will the requirements and feature sets.
With that in mind, the following features are roughly categorized into
"common to many" (including some development/debugging features), and
the above categories.

In addition to the technical features, we need better web presence.  The
existing NetBSD Embedded (http://www.netbsd.org/about/embed.html) web
page needs attention--specifically it needs at least to talk more about
how NetBSD can be (is being) used in embedded applications and why it's
a good (and becoming better) choice.

---++ Handheld/kiosk devices
   * Nano-X in base (small GUI toolkit w/ Win32 compatibility for ease of
     WinCE ports)
      * Native, non-X version of nano-X
   * Input devices and other non-audio things that end up on an AC97 link
   * Better support for graphics and input devices (SDL/KDrive/Qtopia)
     easily cross-compiled and included

---++ Dedicated devices
   * Better support for sensors on ACPI/IPMI/I2C/SMBUS/etc.
      * Hardware monitoring daemon to control fans, etc.
      * Consider linking with power management
      * Consider linking with "diverse sensors & control options" above
   * Tiny & full TCP/IP stack or provide options to shrink existing stack
      * Find a way to make the routing code more pluggable and offer
        leaf-only option (cf. Kantee & Helander 2006 EuroBSDCon)
   * Boot with no userland (no user context-switching)
   * Support for managing diverse sensors and control options (e.g. for
     robotics or industrial kinds of applications)

---++ Network devices
   * Mesh routing protocol implementations (which?)
   * Some kind of extensible, but restricted shell-like interface--perhaps
     like NSH (http://www.nmedia.net/~chris/nsh/)
   * More efficient TCP/networking stack on lower-power hardware

---++ Common
   * USB client support
   * 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
      * Functional samples for firewall, wireless AP, tunnel concentrator,
        VPN appliance, IP router, network storage
      * Easy generation of new, custom platforms with little to no
        duplication of code/configuration
      * Easy maintenance of platforms (easy to upgrade from, say, 5.1 to 7.2,
        maybe 5.99.x to 6.0)
      * Integration with syspkgs
   * More complete crunchgen support for more arbitrary binaries
   * Promotion of syspkgs
   * Better support for read-only (or read-mostly) boot disks
     (esp., etc & var -- also see zeroconf & consider run-time configuration
      like dhcp, named.conf, etc.)
   * Support Zeroconf (DNS-SD, mDNS) with /appropriate APIs/
   * Separation of configuration data and system image (kernel/binaries)
   * Remote console support (via ssh? esp?)
   * POSIX message queues
   * More robust USB (no panics with mounted umass hotplug)
   * Stable Kernel API
   * Miniaturize (or replace) the bloated utilities and daemons in the system.
      * Examples: dhclient(8), dhcpd(8), named(8), host(1), dig(1).
      * Perhaps supply bootp client as option for dhcp-like functionality

---+++ Debug / optimization
   * Power management (conserve power when idle / semi-idle)
      * powertop-like functionality?
      * power usage logging / reporting facilities
   * Remote core dumps (via tftp? ssh? esp?)
   * Remote debugging (via firewire or ip? gdb w/ kdp?, ssh-to-ddb? esp?)
   * Remote gathering of profiling data (gprof at first?)
   * Support for gathering data for Intel VTune
   * Revitalized support for PMCs

---++ Additional h/w support
We should support more open-architecture devices that hobbyists can afford.
A sampling:
   * ADI Pronghorn
   (http://www.adiengineering.com/php-bin/ecomm4/categories.php?category_id=30)
   * Avila Gateworks
   * Chumby
   * Meraki Mini
   * Pep Link
   * RouterBOARD 1xx    (http://www.routerboard.com/rb100.html)
   * RouterBOARD 5xx    (http://www.routerboard.com/rb500.html)
   * Ubiquiti LiteStation
   * 3com ergo audrey (one has been offered for donation)
   * Linksys WRT54G
   * more...

There is also some desire for:
   * Support MMU-less architectures?

---++ Miscellaneous (needs some more understanding)
   * Support for layered security for LKMs (ring support)
   * More standard embedded bootstrap (optional)
      * 2nd-stage bootloader with common features and ability to map from
        u-boot/redboot/other to one NetBSD booter/kernel i/face

-- 
Allen Briggs  |  http://www.ninthwonder.com/~briggs/  |  
briggs%ninthwonder.com@localhost