Hi Marcel,
On 03/01/2013 05:27 PM, Marcel Holtmann wrote:
Let's adapt (and fix if necessary) rtnl instead.
In the near future there is a nicer netlink handling code which is
coming also, so it will require a bit of work in rtnl anyway.
You might want to wait for this maybe. Check this with Marcel.
is ACCT netfilter plain netlink or generic netlink. For generic
netlink, I will be soon pushing src/shared/genl.[ch] to make that
nightmare workable. For plain netlink, we could create a common
src/shared/netlink.c similar to what ELL already does.
As far as I know, since it's under nfnetlink it should be generic.
Yep, nfnetlink is generic, see
linux/include/uapi/linux/netfilter/nfnetlink.h
then I have no idea what you are trying to do.
I figured that I need to some code handling generic netlink messages for
NFACCT. So my netlink.c file is just for that, no specific NFACCT part.
The reference to rntl.c is just because I thought some parts of the code
is doing almost the same. But as you say, no point in trying to share
code between rtnl and generic netlink.
generic netlink has a specific way of working and also specific semantics bound
with it. It is more D-Bus like than you think.
I am well aware of it :)
So without the genl.[ch] I am working on, there is no point in trying to copy
our rtnl.c code for it. That is bound to be a major failure. While generic
netlink is layered on top of standard netlink, it makes no sense to try to
combine them. I have been down that road. Was a mistake.
No, I didn't copy anything from rtnl.c. Instead I mimicked API from the
netlink.c in ELL.
I think my version of (generic) netlink.c is what you are working on
called genl.[ch]. nfacct.c implements the NFACCT specific generic netlink.
Overall, it looks like we agree on how to do it. If you push gen.[ch]
very soonish I can adapt nfacct.c. Doesn't have to be perfect. We can
fix it up on the way.
cheers,
daniel
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
