Re: [PATCH net-next 01/15] tools: ynl: give up on libmnl for auto-ints

[Jakub Kicinski <kuba@kernel.org>]

On Fri, 23 Feb 2024 14:51:12 +0100 Nicolas Dichtel wrote:
> > +static inline __s64 mnl_attr_get_sint(const struct nlattr *attr)
> > +{
> > +	switch (mnl_attr_get_payload_len(attr)) {
> > +	case 4:
> > +		return mnl_attr_get_u32(attr);
> > +	case 8:
> > +		return mnl_attr_get_u64(attr);
> > +	default:
> > +		return 0;
> > +	}
> >  }  
> mnl_attr_get_uint() and mnl_attr_get_sint() are identical. What about
> #define mnl_attr_get_sint mnl_attr_get_uint
> ?

I like to have the helpers written out 🤷️
I really hate the *_encode_bits macros in the kernel, maybe I'm
swinging to hard in the opposite direction, but let me swing! :)

> >  static inline void
> > -mnl_attr_put_uint(struct nlmsghdr *nlh, uint16_t type, uint64_t data)
> > +mnl_attr_put_uint(struct nlmsghdr *nlh, __u16 type, __u64 data)  
> Is there a reason to switch from uint*_t to __u* types?

YNL uses the kernel __{s,u}{8,16,32,64} types everywhere.
These were an exception because they were following libmnl's types.