* jamal <1106576005.1652.1292.camel@xxxxxxxxxxxxxxxx> 2005-01-24 09:13
> On Thu, 2005-01-20 at 10:35, Thomas Graf wrote:
> > > > - Seq counter in netlink, increased evertime a netlink message
> > > > gets processed and returned in ack. A netlink request may contain
> > > > a flag and the expected sequence number and the request gets only
> > > > processed if they match, otherwise the request fails. (my favourite)
> >
> > Do you have any objections on this?
>
> A seq number in netlink is infact a transaction identifier (as opposed
> to a message identifier). We also have a window of 1 for a very good
> reason - simplicty.
> If what you are saying is we muck around seq numbers, i think its a bad
> idea.
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.
> 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.
|