On Mon, 2008-21-04 at 13:50 +0200, Patrick McHardy wrote:


quoted text
> I just noticed the libnl example code already supports this:
> 
> $ ./nl-link-dump env dev eth0
> LINK_NAME=eth0
> LINK_IFINDEX=2
> LINK_FAMILY=unspec
> LINK_TYPE=ether
> ...
> 
> I wouldn't duplicate it for iproute, but rather complete the
> libnl support (I think some object types are still missing
> ENV dump format support) and tell people to use that for
> scripting.

Sounds sensible.
It would be useful to probably port iproute2 to use libnl. Or something
new that provides iproute2 input/output.

on libnl (CC Thomas):
I havent looked at libnl in a long time; it is certainly the right
direction forward - my main contention with it (which i mentioned to
Thomas) is it has too many knobs/hooks. Last conversation we had he told
me it is optional for me to use all those knobs. For a geek that may not
be sufficient answer: if you give me a swiss army knife i need to know
what everything does ;->
Once you go that path network code that provides callbacks in more than
send/recv as well as statefulness (like caching runtime objects which
libnl did when i looked) then you no longer pass the smell-test for
"library" - you are into "framework" domain[1] - which requires more
steep knowledge of the framework to bypass mechanisms provided to you
that you dont like. I tried to port some app back then from libnetlink
to libnl and found it to be extra curve-climbing and abandoned it; i
will revisit at some point.

cheers,
jamal
[1] Python twisted for example falls under "framework"

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html