From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95892 invoked by alias); 3 Jul 2017 18:49:35 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 95863 invoked by uid 89); 3 Jul 2017 18:49:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Daniels, daniels X-HELO: mail-vk0-f45.google.com Received: from mail-vk0-f45.google.com (HELO mail-vk0-f45.google.com) (209.85.213.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Jul 2017 18:49:33 +0000 Received: by mail-vk0-f45.google.com with SMTP id y70so99693985vky.3 for ; Mon, 03 Jul 2017 11:49:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yckU7JYQkA7/kAAVm846dzV3fksV7uEpISsvAgJmK7E=; b=qTYUr/oZM+bb5vyKRaZZz+RYdiyi5jjCO9oBRsvubdLJGnC49e7w5PjN4k/yWHwrUt JvoWJ+GJR65uPjWIIffDpJzffIfDPCay48hYhcEAt9D8mlW4TykPKAD8spyKJRRLFhvs 2b8JrWpT7qz9AAz/Zyp1V+NYu4wS7Sm6Pqr+IY6RvQzNrQ+6RPlpBT74pR5ErYxWLAN3 aIgZVWNsJkgeM9LD/yWrdiC1L8pf4T9hPzYAPnlJwjwxbGlmIBUyePvOAvoREc4BC8Wf KpuPzGd2r4ctDpi3CH/hunYL0x9u1M62E8swrujKW+nIq5Kfbs6hctk/yfl9xc3IJ+tG ZZMQ== X-Gm-Message-State: AKS2vOzMzyWKwYxhmF6hMSAGoq3ohX4sHBZwI/YR6lbqnAjzW/hLgiht 7Y1RpD+Q4YGLtnlztUSgMmfprLufTQI7 X-Received: by 10.31.85.197 with SMTP id j188mr19548858vkb.133.1499107772042; Mon, 03 Jul 2017 11:49:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.22.204 with HTTP; Mon, 3 Jul 2017 11:49:31 -0700 (PDT) In-Reply-To: References: From: David Smith Date: Mon, 03 Jul 2017 18:49:00 -0000 Message-ID: Subject: Re: Generating Kernel module for Other Computers To: Arkady Cc: Daniel Doron , systemtap@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00005.txt.bz2 On Mon, Jul 3, 2017 at 12:17 PM, Arkady wrote: > On Mon, Jul 3, 2017 at 7:17 PM, David Smith 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