Support AF_NETLINK in ktrstruct.

[artemhevorhian_gmail.com]

Summary

Right now, sockaddr_nl parameters are not displayed in kdump output,
however they are present in the structure in ktrace.out file when
ktrace is run.

[markj]

sys/sys/ktrace.h

39

This include should be in kdump.c, not here. In general we try to avoid including headers within headers, when possible.

[artemhevorhian_gmail.com]

Update the revision according the comments of markj@

[markj]

Looks ok

usr.bin/kdump/kdump.c

51

This should be sorted after the sys/ includes. The style(9) man page has some examples.

In this case, netlink/netlink.h should come after netinet/in.h below.

1927

I think it's not useful to print the length and family, those will always be the same. We don't print them for other sockaddr types.

Something like netlink[pid=%u, groups=0x%x] makes more sense to me as a format string.

[artemhevorhian_gmail.com]

Sort the includes according to style(9) and modify

the netlink printf() string.

[melifaro]

Generally LGTM

usr.bin/kdump/kdump.c

1927

It depends on what are the goals of printing.
In my mental model, we start to trace app when something is wrong with the application or we just want to dump the interactions with the kernel. While 99.99% of the cases we'll indeed see the AF_NETLINK and sizeof(struct sockaddr_nl), in the rest cases it may be filled in differently. The thing is that we may be looking at the kdump output to find exactly that..
I definitely agree that in most cases we don't care - so one of the options would be to skip those fields _unless_ they have unexpected values.
It's also with noting that kdump format is not exactly space-optimised and we're still spending a whole line for printing STRU anyway - so maybe being verbose isn't too bad.

[markj]

usr.bin/kdump/kdump.c

1927

Well, this case won't match at all if nl_family != AF_NETLINK. Probably the "unknown address family" message below should include the family.

If the length is wrong, we may indeed care, but probably not: classic unix socket interfaces take the sockaddr length as a separate parameter and typically overwrite the user-supplied length. Indeed, Linux sockaddrs don't have a length field at all. So it is rarely interesting, and it's not printed for the other sockaddr types handled above, which is why I suggested to omit it. I have no objection to including it though.