Re: [B.A.T.M.A.N.] [RFC v2 0/5] batman-adv netlink query API

[Matthias Schiffer <mschiffer@universe-factory.net>]

[-- Attachment #1.1: Type: text/plain, Size: 1973 bytes --]

On 03/18/2016 08:09 AM, Sven Eckelmann wrote:
> On Thursday 17 March 2016 18:04:56 Matthias Schiffer wrote:
>> And here is the new version of the PoC userspace tool.
>> Build with:
>>
>> gcc -o batnl batnl.c $$(pkg-config --cflags --libs libnl-1) -Wall
> 
> Thanks for the patches.
> 
> I've only looked at the test querier for a second and I am a little bit 
> confused that you access things like attrs[BATADV_ATTR_ALGO_NAME] without 
> checking if this is available or that the received message is valid (according 
> to the nla_parse policy).
> 
> I know that this is only a PoC but wanted to mention it in case somebody wants 
> to use it as reference for a batctl/alfred implementation.
> 
> I like that the netlink interface doesn't introduce complex structs at the 
> moment (but I have to think a little bit about it). The unnamed enums freak me 
> out a little bit (names would be nice so it is easier to write kernel-doc for 
> it).
> 
> I just ran the build_test stuff through your branch so you get an early 
> feedback about some common problems. See the attached mail (the unused symbols 
> seem to be only symptoms of the build failures with old kernels < 3.12).
> 
> Kind regards,
> 	Sven
> 

Hi,
regarding the first issue: I guess I should just add validation, as doing
so is simple and can only improve robustness. One line of thought that
seems to be common when dealing with such ABIs is that the kernel would
break its ABI contract by sending invalid messages, and that userspace
behaviour would be unspecified anyways if the kernel misbehaves.

I guess we can just give the enums names. Looking through the other UAPI
files, some enums have names, others don't.

Thanks for the build testing, I haven't put too much thought into the
compat issues yet. The genl_register_family_with_ops error should be easy
to fix, the struct netlink_skb_parms differences might be more problematic.

Regards,
Matthias


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]