Issue 15 in kedr: One KEDR installation for many kernels

[ke...@googlecode.com]

Status: Accepted
Owner: tsy...@gmail.com
Labels: Type-Enhancement Priority-Medium Usability

New issue 15 by tsy...@gmail.com: One KEDR installation for many kernels
http://code.google.com/p/kedr/issues/detail?id=15

Currently, the only way to work with several kernels on one machine is to
have different KEDR installations, one per kernel.
If other application(e.g, testsuite) requires KEDR installed, this
application should share same politics: one application's installation per
kernel. This is needed even if application itself doesn't have kernel-space
part.
Having several installations of one application for same purpose is very
inconvenient.

Support for dkms functionality or similar from KEDR would be very useful.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[ke...@googlecode.com]

Comment #1 on issue 15 by euspec...@gmail.com: One KEDR installation for
many kernels
http://code.google.com/p/kedr/issues/detail?id=15

Yes, that would be useful. I have planned DKMS support for KEDR 1.x for
quite some time.

I hope to release new KernelStrider no later than in 4-6 weeks from now.
After that, I'll concentrate on KEDR 1.x.

If support for DKMS or a similar thing is needed earlier, I think, this
could be done locally.

Ideas are welcome, as usual.

[ke...@googlecode.com]

Comment #2 on issue 15 by tsy...@gmail.com: One KEDR installation for many
kernels
http://code.google.com/p/kedr/issues/detail?id=15

Currently I use different wrapper scripts for run testsuite which use KEDR
on different kernels. It is inconvenient, but is not a critical problem.

As I remember, most of the KEDR tools and utilities are relied on absolute
paths. But '.conf' files for load KEDR core with payloads also support (at
least by spec) loading kernel modules using only there names via 'modprobe'.

So, it can be an option for global installation (when modules are installed
into their 'native' location under /lib/modules/) for use dkms for
build&install modules and for use single modules names in tools.

Of course, many problems arise:
1. Are '.conf' files are the only way to access kernel modules in tools?
2. What should be done with KEDR selftesting in case of dkms (probably,
selftesting should be disabled)
3. For every new kernel some configuration should be done(kernel functions
existence checking, etc.), so we need to have self-sufficient(!) CMake
project with kernel modules to be executing at dkms stage.

[ke...@googlecode.com]

Updates:
Status: Fixed

Comment #3 on issue 15 by tsy...@gmail.com: One KEDR installation for many
kernels
https://code.google.com/p/kedr/issues/detail?id=15

Since rc8d82f2f3cff KEDR has stable multi-kernel build type, which is
described in https://code.google.com/p/kedr/wiki/HowTo_multi_kernel