This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Generating Kernel module for Other Computers
- From: David Smith <dsmith at redhat dot com>
- To: Arkady <arkady dot miasnikov at gmail dot com>
- Cc: Daniel Doron <danielmeirdoron at gmail dot com>, systemtap at sourceware dot org
- Date: Mon, 3 Jul 2017 13:49:31 -0500
- 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> <CANA-60pbSJBW5YEVu_LS6Lb=ZC9DWgaDZoqv0wgHU-AWhmuK-Q@mail.gmail.com>
On Mon, Jul 3, 2017 at 12:17 PM, Arkady <arkady.miasnikov@gmail.com> wrote:
> 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.
I think I see where you are coming from. But, your situation might not
be the same as Daniel's situation.
Even in your situation, you say you've got 3-5 different
distributions. With the existing client/server mechanism, you should
only need 1 vm/system per distro - not one per kernel. Each vm/system
can support multiple kernels from that distro. For example, in
Daniel's case he's trying to support Centos 6.9. One Centos 6.9
VM/system server can support multiple Centos 6.9 kernels.
(As I mentioned earlier, we're moving in the direction of using
containers, but we aren't there yet.)
--
David Smith
Principal Software Engineer
Red Hat