On Mon, 2005-01-24 at 10:06, Thomas Graf wrote:
> I'm not talking of the nlmsg_seq but rather a a sequence number with
> global or nl_family scope. It gets increased whenever a netlink
> message of that family is processed and is returned with the ack. If
> a userspace application wants to enforce atomicy between two requests
> which cannot be batched because a answer is expected in between then
> it could provide the expected sequence number and the request is only
> fullfilled if this is true. Example:
>
> --> RTM_NEWLINK
> <-- answer
> <-- ACK (seq = 222)
> --> RTM_SETLINK (expect = 222)
> <-- ACK
>
> Now if another netlink app interfers:
>
> --> RTM_NEWLINK
> <-- answer
> <-- ACK (seq = 222)
>
> -- other app --
> --> RTM_SETLINK
> <-- ACK (seq = 223)
>
> -- back to first app --
> --> RTM_SETLINK (expect = 222)
> <-- ERROR
>
> The application can then retry it's operation a few times and
> finally give up. The main problem I see is to extend nlmsghdr
> in a way it stays compatible.
The best thing you could get out of this is a warning that something
changed under you i.e doesnt really solve the synchronization issue.
[And a lot more complexity is introduced - if you say you want to change
the netlink header and maintain state in the kernel].
> > My thoughts now are you need to build on top of libnetlink - another
> > library. Example, to administratively bring up a netdevice, one would
> > call something like
> >
> > admin_up("eth0");
> >
> > This is not to say you cant build a competing library to libnetlink, i
> > am just not sure it is worth the effort of having two competing
> > libraries doing almost the same thing (that need maintanance).
>
> I think it is, the feedback is overwhelming and people are already
> contributing to support more netlink users. As I said, 95% of the
> functionality is in iproute2 itself and not libnetlink. It is vital
> to have some kind of library to abstract the low level netlink
> functionality in a simple form to other applications. Currently it's
> quite hard to for example access the tc class tree, one can use
> libnetlink to do the request and parse the answer but everyone needs
> to write their own TLV parsing routines.
Your call really - you are the one who is going to maintain it;->
As for ease of use and avoiding users from knowing details of how
tlvs are put together etc - i think it doesnt matter how thats done
underneath the hood; it is still doable on top of current libnetlink. In
other words whats required, IMO, is something that hides netlink totaly
so that the programmer/user doesnt even get to see TLVs.
cheers,
jamal
|