Received: by 10.223.185.116 with SMTP id b49csp4254403wrg; Tue, 6 Mar 2018 12:28:09 -0800 (PST) X-Google-Smtp-Source: AG47ELsDcSuAOvE/vh/mkP4Ti+X+cluQVKxy005jSo6wlmNLHai+c+wSqaN3s8pu994amSQ0j2I3 X-Received: by 10.98.82.144 with SMTP id g138mr19807866pfb.239.1520368089568; Tue, 06 Mar 2018 12:28:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520368089; cv=none; d=google.com; s=arc-20160816; b=ZJGAT2YKeBJrcrv54wiIrUmqfcgq1pMtK5RmLD7fALnBFcv/yU6NGTTpNH7VmU+Ov6 cmlNy362oQuTND2eGTLz79g7buyTn1GFOA5+K+pQHl4oxwOktkENzIMrtbLbmG+BQg7C pEqOeRNNdaz1M4HJkBWYqM+2sJN5IbRr+bFEc7HYb0hHR4vsAzE20sGbJhhpdEksmt0Z vCQHJZi9w7cBXY23bkZQCW2IF1eJD5c6K2OkSi+3XNJYyAKqrYmpX7JB1lHQdxLZgrgO A6wjrEGa0QgDSYsP9wvqP0ufs8QgofgFJSWG/XJAk685pjVPFKdtzwbix+qDFDdYOhi8 Ceeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=zNfbAnnelHhonamnMIY0pT8WOaLEScEQ3k24hnn/qQc=; b=X0oe+LuzPzKJjIuZIuIiS2i3u51f+Wn1Pu8J0Xu0GYlR/ry+kVx2W24lvp+g21r93g 93p8OQNnkWhChbKxZ0/b4p30lU+4jjHq6ijyFlEY2F1kZRk3Dq6hYv43kbgjvChMNI35 xQfwxeLFw1GeFEEjOrqNnDX7wxgI389hKH/aODrQyg6PQ8oSSiyQBn15CcjRuZSC9izl HZu+kf3AoTz02wIgZjUAmu0WIMKrtWaUf9hF4wCFYNFDrJfTi2Lwd8s/ljJGW6LQdsJY HdfiNYLNC7YwXP8TPfwtG/8/cgVfn0vvfmr+wJqj5L/xX1B5W2YzDJZ5i6xYa9JrGd/F R9cA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ZleqpiU1; dkim=fail header.i=@linux-foundation.org header.s=google header.b=QmrxbzhD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g7si9165589pgp.799.2018.03.06.12.27.55; Tue, 06 Mar 2018 12:28:09 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ZleqpiU1; dkim=fail header.i=@linux-foundation.org header.s=google header.b=QmrxbzhD; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754032AbeCFU1A (ORCPT + 99 others); Tue, 6 Mar 2018 15:27:00 -0500 Received: from mail-ot0-f195.google.com ([74.125.82.195]:40053 "EHLO mail-ot0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750797AbeCFU06 (ORCPT ); Tue, 6 Mar 2018 15:26:58 -0500 Received: by mail-ot0-f195.google.com with SMTP id l12so19606212otj.7; Tue, 06 Mar 2018 12:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zNfbAnnelHhonamnMIY0pT8WOaLEScEQ3k24hnn/qQc=; b=ZleqpiU1YNI9qebwCh5evd04U0ulisv6aql/cJl+RbIkqSxdgZiMUoEupXqOyLIEtS efZ3qtT3UroLdunMLgb0uX3ZJinxn2ENiMsL6ljL5Dv1TMU7/zOUqhTeffXS2eMP9lMo FOwi9S5KrWZDrOi0aaZx7AQEqhflBL7Vl41dSt/qWAW1ivo7Ju68RIkeNQi5WZN3Mjyz laH4qm3GTfz55cPdG8OgzDmpsmgFL5RJKxDkrLO5Nbot+NosfeUyinOqT+Fo+zGVGbTk dy5QWgOfuczjNeZbvTouiaE656QZwq8Savy6ePh6Mt8V/yKuJju75JEwHMyDQx8kvnEi m5kQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zNfbAnnelHhonamnMIY0pT8WOaLEScEQ3k24hnn/qQc=; b=QmrxbzhD+4kA7Zw0VcCa4Jiwb6Hcj5gvwohuO4TcEcddz71+x2/YHOz8oZSM4JcZQB v9NUjlVetjEuMaeS+Z53zqIQp4lWfiKWvW9k5ehIT9F674iHFyZC0qNBbRoYoBkr5tp5 o9GhgW2HPttza6jYnAfkX3V8guEvJoU2VWc34= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zNfbAnnelHhonamnMIY0pT8WOaLEScEQ3k24hnn/qQc=; b=bV4wOldIBiOOeTTwLWTqHiL5zR+bMD2+XUBjxgPWAM0lMGUV09UuwGRQdjrkLqqngA bt3ShaG5BlO9sMUqFfkmefM4Uc+F90qiUFFsnDunVjgypslO2v5nfPlz5are85B+6UmI HBMqq/uUMvtJtFhw5ik8aZvwIx8wKBSPX06Lp76d3O7PdjZYyYuFLXX5hd3xI7xexij6 KJBhpxQFuM3vpHb3WHwWTK0Yrv/beV3M+JVSPvlE0Jtsd4/0NmagzjQZGu6c3vd/dPsR /80v8HYdm4lSKqzMsc7RRijjyh/r21dk4PEr0gw9DMHOGKqyB7yWTzlzRvJQfyOaw5dc puMA== X-Gm-Message-State: AElRT7G6l0LkCkLbGBfRAo7yk5u9AgHHkM7Mj0Kjh8qaUKbdEjwGVD1+ j3Cr13pudz1uh6f8EjHlCoOKkytXwoN3a7TdYEQ= X-Received: by 10.157.33.51 with SMTP id i48mr11710706otb.343.1520368017519; Tue, 06 Mar 2018 12:26:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.154.82 with HTTP; Tue, 6 Mar 2018 12:26:56 -0800 (PST) In-Reply-To: References: <20180306013457.1955486-1-ast@kernel.org> From: Linus Torvalds Date: Tue, 6 Mar 2018 12:26:56 -0800 X-Google-Sender-Auth: tPpNSNuIQPC5VwFQNywRh4oMSnQ Message-ID: Subject: Re: [PATCH net-next] modules: allow modprobe load regular elf binaries To: Andy Lutomirski Cc: Alexei Starovoitov , "David S. Miller" , Daniel Borkmann , Greg KH , "Luis R. Rodriguez" , Network Development , LKML , kernel-team , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 6, 2018 at 12:01 PM, Andy Lutomirski wrote: > > I assume I'm missing some context here, but why does this need to be > handled by the kernel rather than, say, a change to how modprobe > works? Honestly, the less we have to mess with user-mode tooling, the better. We've been *so* much better off moving most of the module loading logic to the kernel, we should not go back in the old broken direction. I do *not* want the kmod project that is then taken over by systemd, and breaks it the same way they broke firmware loading. Keep modprobe doing one thing, and one thing only: track dependencies and mindlessly just load the modules. Do *not* ask for it to do anything else. Right now kmod is a nice simple project. Lots of testsuite stuff, and a very clear goal. Let's keep kmod doing one thing, and not even have to care about internal kernel decisions like "oh, this module might not be a module, but an executable". If anything, I think we want to keep our options open, in the case we need or want to ever consider short-circuiting things and allowing direct loading of the simple cases and bypassing modprobe entirely. Linus