Let me suggest that one likely design target will
be multi-link residential networks that probably
include energy management CPEs as well as one or
several 6LoWPANs. We must anticipate automated ULA
prefix delegation, etc. as well as the need for site-
local multicast. Here are a couple of relevant I-Ds:
http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements
http://tools.ietf.org/html/draft-lynn-dnsext-site-mdns
Regards, -K-
On 3/30/11 11:58 AM, Felix Fietkau wrote:
On 2011-03-30 5:43 PM, Alexander Gordeev wrote:
В Wed, 30 Mar 2011 17:17:01 +0200
Jo-Philipp Wich<x...@subsignal.org> пишет:
Hi,
no I have no list yet but it boils down to the fact that the current
network and interface setup mechanisms are rather constrained, old and
inflexible.
Big problems are the lack of statefulness, the tendency for race
conditions, the inability to properly nest protocols and the limited
featureset of the ash shell which will not allow for complex interface
operations like calculating ULAs etc.
Felix has started working on netifd, which will at some point supersede
the current network setup scripts with an rpc capable daemon written in
C for better access to kernel APIs, ability to listen on netlink
events etc.
Once this is done, we can start to implement all the IPv6 requirements
in a clean way.
Very interesting, but there are also projects like connman
(connman.net) or network manager. I think the latter is bloated but the
former is intended for embedded devices from the very beginning. What's
wrong with connman?
connman seems to be centered around one specifific use case - having a
mobile device access the internet through multiple connections.
netifd will be able to manage even complex interface configurations with
a mix of bonding, vlans, bridges, etc. and handle the dependencies
between interfaces properly - and of course all that without adding
unnecessary bloat.
BTW, what's the difference between ubus and dbus? I didn't find any
documentation...
D-Bus is bloated, the pure C API is very annoying to use and requires
writing large amounts of boilerplate code. In fact, the pure C API is so
annoying that its API documentation even states: "If you use this
low-level API directly, you're signing up for some pain."
ubus is tiny (12k library, 13k daemon, 6k CLI) and requires only two
small libraries (json-c for the CLI only, and libubox).
It has the advantage of being easy to use from regular C code, as well
as automatically making all exported API functionality also available to
shell scripts with no extra effort.
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
