Hi Daniel, >>>>>> 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.
I have to fix the handling of nested attributes for building messages. And the weird fact that you can also send messages in network endian instead of host endian. After that, it should be ready. There is also one funny piece with multi part messages that I need to figure out. The mostly difference is that the generic netlink name has a lifetime similar to the well known name in D-Bus. It can change over time. And autoloading of generic netlink kernel modules is also funny thing that needs to be taken into account. Not to mention multicast messages. Just a bit of history, previously I tried to make netlink and generic netlink work with the same API. However there is a problem here. With netlink you operate on static constants for commands and multicast. With generic netlink these are all strings that you have to resolve into their number parts. And the numbers can and will change during boot and at runtime (if you load/unload modules). This fact makes it almost impossible to create a common API that is simple. I can show you my first attempt. It was horrible. My second attempt is now separate APIs. One for netlink and one for generic netlink. That has been worked out in my tests rather pleasant so far. Regards Marcel _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
