Hi,
On Mon, Oct 29, 2018 at 04:19:03PM +0100, Pablo Neira Ayuso wrote:
> On Fri, Oct 26, 2018 at 03:01:38PM +0200, Phil Sutter wrote:
> > The basic principle is to not return a JSON object freshly created from
> > netlink responses, but just update the existing user-provided one to
> > make sure callers get back exactly what they expect.
>
> Applied, thanks Phil.
>
> > To achieve that, keep the parsed JSON object around in a global variable
> > ('cur_root') and provide a custom callback to insert handles into it
> > from received netlink messages. The tricky bit here is updating rules
> > since unique identification is problematic. Therefore drop possibly
> > present handles from input and later assume updates are received in
> > order so the first rule not having a handle set is the right one.
>
> You can use the netlink sequence number to correlate the rule that you
> are adding with the object that the kernel gives us. The kernel will
> reply including the sequence number of the original request in the
> reply you get. Like this, you will not need obj_info_matches() and
> such I think. In case this helps you simplify this code.
That's an interesting idea, but I don't think it would fly: netlink
seqnum is per batch and potentially there are multiple add commands
contained in it. So although I could make sure the kernel's reply
matches the current request, I still have to figure out which JSON add
command to update. Or am I missing something?
Thanks, Phil
