Re: [PATCH iproute2-next v2 1/3] Add, show, link, remove IOAM namespaces and schemas

[David Ahern <dsahern@gmail.com>]

On 7/29/21 3:51 AM, Justin Iurman wrote:
> Hi David,
> 
>>> +static void print_schema(struct rtattr *attrs[])
>>> +{
>>> +	__u8 data[IOAM6_MAX_SCHEMA_DATA_LEN + 1];
>>> +	int len;
>>> +
>>> +	print_uint(PRINT_ANY, "schema", "schema %u",
>>> +		   rta_getattr_u32(attrs[IOAM6_ATTR_SC_ID]));
>>> +
>>> +	if (attrs[IOAM6_ATTR_NS_ID])
>>> +		print_uint(PRINT_ANY, "namespace", " [namespace %u]",
>>> +			   rta_getattr_u16(attrs[IOAM6_ATTR_NS_ID]));
>>> +
>>> +	len = RTA_PAYLOAD(attrs[IOAM6_ATTR_SC_DATA]);
>>> +	memcpy(data, RTA_DATA(attrs[IOAM6_ATTR_SC_DATA]), len);
>>> +	data[len] = '\0';
>>> +
>>> +	print_string(PRINT_ANY, "data", ", data \"%s\"", (const char *)data);
>>
>> The attribute descriptions shows this as binary data, not a string.
> 
> Indeed. Maybe should I print it as hex... What do you think is more appropriate for this?

./tc/em_meta.c has print_binary() but it is not json aware.

devlink has pr_out_binary_value which is close. You could probably take
this one and generalize it.


> 
> 
>>> +static int ioam6_do_cmd(void)
>>> +{
>>> +	IOAM6_REQUEST(req, 1036, opts.cmd, NLM_F_REQUEST);
>>> +	int dump = 0;
>>> +
>>> +	if (genl_family < 0) {
>>> +		if (rtnl_open_byproto(&grth, 0, NETLINK_GENERIC) < 0) {
>>> +			fprintf(stderr, "Cannot open generic netlink socket\n");
>>> +			exit(1);
>>> +		}
>>> +		genl_family = genl_resolve_family(&grth, IOAM6_GENL_NAME);
>>
>> The above 2 calls can be done with genl_init_handle.
> 
> Didn't know that one, thx for the pointer.
> 
> 
>>> +int do_ioam6(int argc, char **argv)
>>> +{
>>> +	bool maybe_wide = false;
>>> +
>>> +	if (argc < 1 || matches(*argv, "help") == 0)
>>> +		usage();
>>> +
>>> +	memset(&opts, 0, sizeof(opts));
>>> +
>>> +	if (matches(*argv, "namespace") == 0) {
>>
>> matches has been shown to be quite frail. Convenient for shorthand
>> typing commands, but frail in the big picture. We should stop using it -
>> especially for new commands.
> 
> Sure. What do you suggest as an alternative?
> 

full strcmp.