This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Generating Kernel module for Other Computers
- From: Arkady <arkady dot miasnikov at gmail dot com>
- To: David Smith <dsmith at redhat dot com>
- Cc: Daniel Doron <danielmeirdoron at gmail dot com>, systemtap at sourceware dot org
- Date: Mon, 3 Jul 2017 20:17:57 +0300
- Subject: Re: Generating Kernel module for Other Computers
- Authentication-results: sourceware.org; auth=none
- References: <CAFwN=+wqOCx0FL6+CdH3BZkiFaie_dVF161YFkNuck8O+kxY+A@mail.gmail.com> <CANA-60qRMwiVE9KReZkUoLn9Tx5=Jx+6WPv5c5j4iguSpP7HxQ@mail.gmail.com> <CAKFOr-ZL=g6E8qZYTYaTLz46pKJGYsyP2uZGkN+rDV7osyYh0A@mail.gmail.com>
On Mon, Jul 3, 2017 at 7:17 PM, David Smith <dsmith@redhat.com> wrote:
> Another approach here would be to use the existing systemtap
> client/server mechanism. You'd set up a server for each distro you
> wanted to support (note that each compile server system doesn't have
> to be a real system, it could be a virtual machine). In the
> background, the systemtap servers use avahi to broadcast what kernel
> versions they support.
>
This way to compile and deploy the drivers is great for situations
when we can control the environment. For example, we can install avahi
library, stap-run, allow UDP connections, multicast.
There are other scenarios as well. I have to deliver the driver
precompiled for all kernels existing in the network. I can not assume
that the production server can connect to anything besides a
proprietary service running above websocket. I am not allowed, for
example, to compile modules on the fly and deploy w/o testing the
drivers in the lab first. I have to support between 10 to 20 kernels
across 3-5 different distributions in a single deployment. If I choose
VM route - 20GB per VM - I start to feel the storage costs.
For a large number of different kernels I do not see many alternatives
besides container/chroot.
>
> --
> David Smith
> Principal Software Engineer
> Red Hat