inetdiag libnl library?

[Joe Damato]

On Thu, Jul 4, 2013 at 12:56 PM, Thomas Graf <tgraf at suug.ch> wrote:
> On 07/03/13 at 07:50pm, Joe Damato wrote:
>> Hi -
>>
>> Is there any interest in seeing a libnl-inetdiag library in the spirit
>> of libnl-route etc?
>>
>> I started to carve one out just to experiment. I pushed my changes to
>> github and submit a pull request[1]. This code doesn't do too much,
>> but it let me write a simple user program to get some socket stat like
>> information.
>>
>> It's not even close to being near a stage where it could be merged,
>> but I wanted to see if there was any interest in seeing this before
>> going any deeper.
>
> For the record: As stated in the pull request already, I'm happy
> to merge such patches as soon as they are in a mergeable state.

Thanks for the reply and sorry for the spam; I wan't sure if you
checked github so I pinged the mailing list as well.

I've made pretty good progress and am getting close to having some
code ready for review.

Running into one thing and was curious if you had thoughts on what
would be the most appropriate way to solve it. The latest kernels and
their userland includes have support for inetdiag attributes that may
not exist in the kernel and headers of recent-ish distros (one example
is: INET_DIAG_SKMEMINFO which appears for the first time in 3.3.0, as
well as: INET_DIAG_SHUTDOWN which appears in 3.8).

It seems like there are a few options to deal with this:

1.) Support the latest inetdiag attributes on the latest
kernels/headers. Some users on older distros will have trouble
building the library.

2.) Add several configure.ac checks to determine which attributes and
structures are part of the build machine. Include a series of ifdefs
in the libnl-idiag code to enable/disable the attributes as necessary.

3.) I am currently using linux/inet_diag.h which has structures for
dealing with the raw message that comes off the fd. I could add a
bunch of defines/enums to libnl to support all the attributes that the
latest kernel supports, but then we'd end up using a struct definition
from the system-provided inet_diag along with a set of enums/defines
that are different from what is found in inet_diag.h This might be OK;
not sure what the libnl policy is on this.

4.) Avoid "newer" attributes entirely and only support a smaller
subset of the attributes that inetdiag suports on the latest kernels.

Let me know what you'd prefer to see and I'm happy to go down that path.

Thanks,
Joe