From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68158C282DA for ; Tue, 16 Apr 2019 16:47:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 36040206B6 for ; Tue, 16 Apr 2019 16:47:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lixom-net.20150623.gappssmtp.com header.i=@lixom-net.20150623.gappssmtp.com header.b="fG2iQSaa" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730027AbfDPQr3 (ORCPT ); Tue, 16 Apr 2019 12:47:29 -0400 Received: from mail-it1-f193.google.com ([209.85.166.193]:33268 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730007AbfDPQr2 (ORCPT ); Tue, 16 Apr 2019 12:47:28 -0400 Received: by mail-it1-f193.google.com with SMTP id v8so3159007itf.0 for ; Tue, 16 Apr 2019 09:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UNeYJRA6DqdqQQDusaGwYqXolUas5X2/Vxw7bBLr77M=; b=fG2iQSaaswqIND/hiD0tQYjK/CoCissJABBrVNVJ4Lhz6IrQ1bnJ2I4a3fMEv0oX0d lh1qzJeS9En6IRf/uggR/nP0q8aykjDDyc4Q8QMub7Qar0bwa8BdmY2z2lAmZn1oUM9r +mrJb/fmluySDm5QrL7LKjyuID+zn7mQ9mCSK9KjmY1OLmypba0kufZSkRnsyZCL1Mrc 8MX9JjHZ+bY3leIxKQy4o94JjtyzZysFbL9KS8TjnXyAeHWyewW6++4s8hL1j5mTsGVZ HLoQlmaSmPHOehwuw4x5MsSABF1D4OPr3ViA/1jrBxe5Z4GykW+qmLLao0Uvr69dGEem gpEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UNeYJRA6DqdqQQDusaGwYqXolUas5X2/Vxw7bBLr77M=; b=O4b0Q7s8l9VBEtVoTgqEj02KZ6wlbhv4CjCYw/LOO23hI4IaE1w9guj6HEL5ddtC6t eTn/A+HPh8UtwzgMbJ3AGX125LNF+b7tqIDDIdsgNs/VyrmdVULs1ZheYlArJl65R3u2 7xhgvseZ0YtJDb7hEfr0p99k7/QXF3E+f39gNp+AZrQGwBBN0dBZkLjDE6kH17Ow+1dR bCEhENf6Gyg2Lz1LlAQPRx6zdgqE5c9xR/ZuwhxAOLT10mXEpRbq6W6zR9yg+E72MZwt kTbUFKUh0NL/z8tEuL+0Q3JYlD6NbdOkU+1Qo4fzlCzC7zHj9U5RFpJJmXp1UCDMnFxI WD0A== X-Gm-Message-State: APjAAAWSbJLypnkBlBhv6MXJDW2jTe5K5f/VQnQ9pxjD7P6MUHfgRUUM CRaBwNpu/KsNgNKVk57qhH8gW+Yfph/jNT8IWVHQpQ== X-Google-Smtp-Source: APXvYqwFUZ5eDHZPk/N8L9f/9OI8M6K3Y4t0h7t0AXKVOwqiHPmHZC1Jx6bk24cZRzHgKiz63xdvn1Z/m7ueVAyW4u8= X-Received: by 2002:a24:7c9:: with SMTP id f192mr31475988itf.97.1555433247471; Tue, 16 Apr 2019 09:47:27 -0700 (PDT) MIME-Version: 1.0 References: <20190408203601.GF133872@google.com> <20190411031540.ehezr6kq7ouobpzx@ast-mbp.dhcp.thefacebook.com> <20190415104109.64d914f3@gandalf.local.home> <20190416083306.5646a687@gandalf.local.home> <20190416124939.GB6027@kroah.com> <20190416130440.GA7944@localhost> In-Reply-To: From: Olof Johansson Date: Tue, 16 Apr 2019 09:47:16 -0700 Message-ID: Subject: Re: [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier To: Karim Yaghmour Cc: Joel Fernandes , Greg Kroah-Hartman , Steven Rostedt , Kees Cook , Olof Johansson , Alexei Starovoitov , Joel Fernandes , Linux Kernel Mailing List , Qais Yousef , Dietmar Eggemann , Manoj Rao , Andrew Morton , Alexei Starovoitov , atish patra , Daniel Colascione , Dan Williams , Guenter Roeck , Jonathan Corbet , Android Kernel Team , "open list:DOCUMENTATION" , "open list:KERNEL SELFTEST FRAMEWORK" , linux-trace-devel@vger.kernel.org, Masahiro Yamada , Masami Hiramatsu , Randy Dunlap , Shuah Khan , Yonghong Song 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, Apr 16, 2019 at 6:32 AM Karim Yaghmour wrote: > > > On 4/16/19 9:04 AM, Joel Fernandes wrote: > > On Tue, Apr 16, 2019 at 02:49:39PM +0200, Greg Kroah-Hartman wrote: > >> On Tue, Apr 16, 2019 at 08:33:06AM -0400, Steven Rostedt wrote: > >>> On Mon, 15 Apr 2019 22:50:10 -0500 > >>> Kees Cook wrote: > >>> > >>>> On Mon, Apr 15, 2019 at 9:41 AM Steven Rostedt wrote: > >>>>> I agree with this assessment. We shouldn't use config.gz as precedence > >>>>> for this solution. config.gz should have been in debugfs to begin with, > >>>>> but I don't believe debugfs was around when config.gz was introduced. > >>>>> (Don't have time to look into the history of the two). > >>>> > >>>> I don't agree with this: /proc/config.gz is used by a lot of tools > >>>> that do sanity-check of running systems. This isn't _debugging_... > >>>> it's verifying correct kernel builds. It's a fancy version of checking > >>>> /proc/version. > >>>> > >>> > >>> Then we should perhaps make a new file system call tarballs ;-) > >>> > >>> /sys/kernel/tarballs/ > >>> > >>> and place everything there. That way it removes it from /proc (which is > >>> the worse place for that) and also makes it something other than debug. > >>> That's what I did for tracefs. > >> > >> As horrible as that suggestion is, it does kind of make sense :) > >> > >> We can't put this in debugfs as that's only for debugging and systems > >> should never have that mounted for normal operations (users want to > >> build ebpf programs), and /proc really should be for processes but that > >> horse is long left the barn. > >> > >> But, I'm willing to consider putting this either in a system-fs-like > >> filesystem, or just in sysfs itself, we do have /sys/kernel/ to play > >> around in if the main objection is that we should not be cluttering up > >> /proc with stuff like this. > >> > > > > I am ok with the suggestion of /sys/kernel for the archive. That also seems > > to fit well with the idea that the headers are kernel related and probably > > belong here more strictly speaking, than /proc. > > This makes sense. And if it alleviates concerns regarding extending > /proc ABIs then might as well switch to this. > > Olof, what do you think of this? In practice we've been more lenient with changes to /sys over time, so I think this might be a reasonable compromise. I still think that a filesystem view is the cleanest way to do this, but I won't push back from this going in. It does solve a real problem, and if we want a different format later we can revisit it then. -Olof