Some Linux networking plugins do not work on newer kernels

[GoogleCodeExporter]

Some of the networking data structures have changed in the later 3.x kernels.  
This patch fixes support for these plugins.

Original issue reported on code.google.com by Joe.Sylve@gmail.com on 29 Jun 2012 at 2:20

Attachments:

• 3.X.NetworkingFix.patch.txt

[GoogleCodeExporter]

This issue was closed by revision r1968.

Original comment by mike.auty@gmail.com on 1 Jul 2012 at 11:14

• Changed state: Fixed

[GoogleCodeExporter]

Thanks very much.  One thing to think about is using the kernel version 
metadata to make it more easier to see which of multiple different 
possibilities should be used any why.  Hopefully the structs don't differ 
within a single kernel version.

@attc, that makes me wonder, do we correctly populate the major/minor/build 
metadata, and if not, can we do it automatically from the system map?

Original comment by mike.auty@gmail.com on 1 Jul 2012 at 11:17

[GoogleCodeExporter]

I am not sure we populate the major/minor stuff properly (or even if we do that 
at all), but I wouldn't trust it even if we did. Distros are always back 
porting patches so they don't have to fully update their 'stable' kernels to 
newer versions which pretty much breaks any reliance on the kernel version 
numbers. 

In this patch though, the checks in route_cache and in netstat would be cleaner 
if put into linux_overlay and wouldn't break anything.

Original comment by atc...@gmail.com on 1 Jul 2012 at 6:56

[GoogleCodeExporter]

The major/minor/build numbers are not actually relevant for linux (or indeed 
OSX now). These numbers are mostly used to select profiles for different 
versions of windows from a library of extracted vtypes (e.g. Win7SP2x64 is a 
profile which corresponds to a specific major/minor versions). Since on linux 
the profiles are already specific to the relevant kernel we do not need to tag 
them specifically.

The problem is really what to do when we have specific overlays which should be 
applied for different kernel versions. Perhaps a better system is to 
specifically apply the overlays based on the kernel symbols themselves (e.g. 
check for a field name, and apply an overlay if it exists/does not exist).

Original comment by scude...@gmail.com on 1 Jul 2012 at 7:31

[GoogleCodeExporter]

Structs can differ across the same kernel version due to different config 
setups.  This is another thing to consider.

Original comment by Joe.Sylve@gmail.com on 2 Jul 2012 at 12:23

[GoogleCodeExporter]

Joe,
  Exactly, this is why you always need to generate vtypes for your exact kernel version. That is my whole point - major/minor numbers are meaningless in linux because you already have the exact vtypes for your kernel. 

The problem is how to choose different overlays - as the names of structs and 
fields etc change from version to version. We can use version numbers for this, 
or better yet just auto detect the fields in the struct (i.e. if a field 
changed name from foo to bar, we can check for existence of field foo, and 
simply add an overlay to rename it back using a synonym (bar -> foo)). This way 
the plugins themselves remain clean because they just assume there is a field 
named "foo", even on newer kernel version (which have no such field).

Original comment by scude...@gmail.com on 2 Jul 2012 at 12:29