Hi,

Thanks for the comments.

quoted

quoted

+struct gcm_iv {
+	union {
+		u8 secure_channel_id[8];
+		sci_t sci;
+	};
+	__be32 pn;
+};

Should this be __packed?

I think that's not necessary here.

Yeah, there's probably no way a compiler could ever do something with
it that's not the same as packed, but it seems to me that just out of
convention structs that have some wire-format meaning should usually be
__packed. But it's your call. I'm not even entirely sure it has a wire-
format or similar meaning, although the name indicates it gets used
into the encryption and must be exactly these 12 octets.

quoted

That way, you have the same policy for everything and also don't
have
to play tricks with the aliasing since the top-level attributes
actually exist now, coming from the same namespace & policy.

That's a good idea, I'll have a look today.
I don't really like the aliasing games I have to play, but I'd like
to
keep the RXSC attributes separate from the SA attributes, I think it
looks cleaner (the first RFC had everything in the same policy:
http://www.spinics.net/lists/netdev/msg358152.html).

Ah, I see. Keeping it separate makes sense, but you can still achieve
that like this:

msg = [ifindex -> 7,
       rxsc -> [ sci -> 2, ...
               ],
       ...
      ]

with nested data. I'd also do the same for the stats and a whole bunch
of others too, I guess. I tend to imagine it as a kind of "dict of
dicts" (the message with nested).

Thanks,
johannes