On 6/5/07, Allen Briggs <briggs@netbsd.org> wrote:
> On Tue, Jun 05, 2007 at 09:42:31AM +0300, Ivo Vachkov wrote:
> > * tiny & full tcp/ip stack (like QNX for example)
>
> If we're defining a "tiny & full" tcp/ip stack, it would be useful
> to identify what "tiny" and "full" mean.  Can you elaborate?  I
> have some idea what I would mean by that, but would like to hear
> what you would be willing to give up.

I'll define it this way. In embedded systems you usually have two
types of systems that require network capabilities. Those that use the
network for transport data (client devices) and those that make sure
others can transport data (infrastructure devices - switches, routers,
etc). This, of course, is not absolute. And
1) tiny would be a network stack that includes protocols that are
mostly used: ARP, IP, ICMP, UDP, TCP, etc. Probably routing and packet
filtering will be here too.
2) full would include in addition to those IPv6, IPSec, SCTP, advanced
firewalling, policy-based routing, etc.

> > * most of the base system tools as installable packages
>
> Why, specifically?  I wonder if this is similar to or different
> from the "build to image" functionality I mentioned.  The idea
> there is that you would have some kind of configuration tied to
> the source tree and you would build a complete "firmware" image
> directly.

Consider the following situation: you have built an image with the OS
and tools you need. Several months later you find that now you need
tcpdump or tcpblast or vndconfig or what so ever you missed before.
Instead of rebuilding the image for one file it'd be great to be able
to add it (if, of course, the device support it). You can find
something very similar in OpenWRT project.

> > * mesh routing protocol implementations
>
> What protocols?  References?

http://en.wikipedia.org/wiki/Ad_hoc_routing_protocol_list

> > * sensor support
>
> What kind of sensor support?  I know that we can do a good deal
> better on x86, but we do have a fair number of sensors supported
> in base right now.  Are you just talking about hardware support
> or software / monitoring / alarms / etc.?

This is more like a pure design. A stable API with a formal language
(or just a way) to describe what kind of data is expected from the
sensors will be good starting point to run NetBSD as a node in
industrial installations.

> > * modular 'control-external-hardware' API
>
> Are there any implementations that you know of out there?  Either
> as examples or things that might be worth importing?

Close to the one above. If NetBSD can offer API or framework for
drivers and control mechanisms for robots you can expect interest on
using it in that area too. Yes, NetBSD supports the CPU, but it's not
the only component in a modern robot. Microsoft started this with
Robotics Studio. And now several manufacturers support them.

> Thanks again!
> -allen
>

-- 
"UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity." Dennis Ritchie