Closed GoogleCodeExporter closed 8 years ago
This issue was closed by revision r1968.
Original comment by mike.auty@gmail.com
on 1 Jul 2012 at 11:14
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
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
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
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
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
Original issue reported on code.google.com by
Joe.Sylve@gmail.com
on 29 Jun 2012 at 2:20Attachments: