Re: Looking ahead

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

On Wed, Jun 06, 2007 at 05:14:36PM +0300, Ivo Vachkov wrote:
> 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.

OK.  Thanks for that definition.  I would actually have divided it a
little differently.  I tend to think of sort of four different types:

        1) Devices with a network connection for control (perhaps
           a weather station or similar)
        2) Devices that want to move a lot of data (perhaps a
           NAS device),
        3) Devices that need to route / bridge networks (perhaps
           a wireless access point), and
        4) Infrastructure types of devices.

Especially with #2 - #4, there are a bunch of different sizes of
devices with a number of different protocol needs.  And the boundaries
are certainly blurred in some cases--especially #2 & #3.  In general,
I think there's probably a reasonable need for:

        1) ARP/IP/ICMP/UDP/TCP (& maybe IPV6/ICMP6 soon?)
        2) 1 + IPSec
        3) 1 + filtering & routing
        4) 1 + policy routing

And various combinations.  Which is kind of what we have now with
options, but with the options stripped, our stack is not really
"tiny"--although perhaps better when routing is ripped out.

> 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.

Fair enough.  Thanks for articulating that.

> >> * mesh routing protocol implementations
> >What protocols?  References?
> http://en.wikipedia.org/wiki/Ad_hoc_routing_protocol_list

That's a LOT of stuff.  I think it would be best for folks who are
more familiar with that space to suggest a path for which protocols
make sense for various applications.  I don't see a need to be fully
FLAC (Four-Letter Acronym Compliant).

> >> * sensor support
> 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.

Ah, OK.

> 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.

I'm not sure that I'd want to use NetBSD for robotic control without
some more real-time "guarantees".  But I suppose there are some
places where that's less of a concern as we're "good enough".

Again, are there existing designs for sensor / control that would
make sense to implement or adopt?  Or is this a case where there's
a void and you're suggesting that it be filled?  Do you have interest
in looking into this?

Thanks again for the informative reply,
-allen

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