From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 79F057D08A for ; Wed, 10 Apr 2019 15:16:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733078AbfDJPQP (ORCPT ); Wed, 10 Apr 2019 11:16:15 -0400 Received: from mail-it1-f196.google.com ([209.85.166.196]:50294 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733105AbfDJPQO (ORCPT ); Wed, 10 Apr 2019 11:16:14 -0400 Received: by mail-it1-f196.google.com with SMTP id q14so4038463itk.0 for ; Wed, 10 Apr 2019 08:16:14 -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=xXXoU6/FqhffNVx13TnuqZws2BBVOxxAPM7i3tEN7Gk=; b=cKFn1n3jYl3MDH5QBleg3GyZt9fGOMW0AOVk5V6g6+FahiMo/Yni6xpg1MBz2vDqwE jkLTyVfI/9w9tiSrfl7m+VqNrbiN/mOa2q2/xkEozcSzmbrwuYhOEyLbuaf6loxAKX6n 2mNl5at8paa3YhadKIfZXAC+WI0PdMzHkELtW/4yxb6V5MY4jwm6H+iXsMS6FEiZ1l4z lvgE8LF8+Ggk7FGbOTPjJdFeIz6Zm4qQ6v2cVZhUFMkhZHDm3eVvrlpPyE+R+TpxIE7E 0fIY3eh5s84Z0Yq4g1irQ2YBwCoWCY+v6e8DV0BFyoC4s6sBAyOuniNLQuKlXnfmyyQw dCOQ== 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=xXXoU6/FqhffNVx13TnuqZws2BBVOxxAPM7i3tEN7Gk=; b=My6OAfk9ZTQ0mppDBXQI1fgNQQJsW7BofBugTUYrrDSexrOVyDGqacuR974Mb7kXA/ C3zu9qYMIbqTSbKgq0f7hSp6fYve0LEcFql3HXAQpi2WOlI8W/w1DWA1+ejspCJTfORB SLruUd4MZNzKXiDTd4o+POOCBuU66/1ocXsWQH/Zh1+yy/RHgUEvyMGeICu37HCdAYyT WmwgQF8e3wXNCslb0RehEVVVCXx2DD3o4mzyO5NeD5YuO08UMCxzVYeePUYnvXVH08JK tiU+voKUNwEIjjP671ibhZsQ3/cVwhCn1JJryE+XducQDoabnqSauUU6si4qQ/L7y3cP A4Yw== X-Gm-Message-State: APjAAAURJY9jA950vlVPp/auhPDwQrEYq2q+hSuwg+eRwqMt3bqh56PG FfPYyLV2fVTU1gXj6hcKFz7CpvU1jupJSNGQlHty4g== X-Google-Smtp-Source: APXvYqxni5IADu3FF8FlZg+Ln4rHXEKRkaB44FhG/joIhG3TELx5Wv9r5dL3+NTYR01YmHFm91lgDHZM5+wOe8dfTck= X-Received: by 2002:a24:2458:: with SMTP id f85mr2181063ita.83.1554909373652; Wed, 10 Apr 2019 08:16:13 -0700 (PDT) MIME-Version: 1.0 References: <20190320163116.39275-1-joel@joelfernandes.org> <79b6bdbc-890a-5a51-7fa1-aec57889046a@opersys.com> In-Reply-To: <79b6bdbc-890a-5a51-7fa1-aec57889046a@opersys.com> From: Olof Johansson Date: Wed, 10 Apr 2019 08:15:59 -0700 Message-ID: Subject: Re: [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier To: Karim Yaghmour Cc: Joel Fernandes , Linux Kernel Mailing List , Qais Yousef , Dietmar Eggemann , Manoj Rao , Andrew Morton , Alexei Starovoitov , atish patra , Daniel Colascione , Dan Williams , Greg Kroah-Hartman , Guenter Roeck , Jonathan Corbet , Kees Cook , Android Kernel Team , "open list:DOCUMENTATION" , "open list:KERNEL SELFTEST FRAMEWORK" , linux-trace-devel@vger.kernel.org, Masahiro Yamada , Masami Hiramatsu , Randy Dunlap , Steven Rostedt , Shuah Khan , Yonghong Song Content-Type: text/plain; charset="UTF-8" Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Mon, Apr 8, 2019 at 1:52 PM Karim Yaghmour wrote: > > > Hi Olof, > > On 4/8/19 12:29 PM, Olof Johansson wrote: > > Sorry to be late at the party with this kind of feedback, but I find > > the whole ".tar.gz in procfs" to be an awkward solution, especially if > > there's expected to be userspace tooling that depends on this > > long-term. > > > > Wouldn't it be more convenient to provide it in a standardized format > > such that you won't have to take an additional step, and always have > > it in a known location? > > > > Something like: > > > > - Pseudo-filesystem, that can just be mounted under > > /sys/kernel/headers or something (similar to debugfs or > > /proc/device-tree). > > - Exporting something like a squashfs image instead, allowing > > loopback mounting of it (or by providing a pseudo-/dev entry for it), > > again allowing direct export of the contents and avoiding the > > extracted directory from being out of sync with currently running > > kernel. > > > > Having to copy and extract the tarball is the most awkward step, IMHO. > > I also find the waste of kernel memory for it to be an issue, but > > given that it can be built as a module I guess that's the obvious > > solution for those who care about memory consumption. > > One of the things I pointed out earlier in the thread is that > /proc/config.gz has already set a precedent as to the interface for this > sort of artifact. It's a plain compressed file and it's directly > accessible from toplevel /proc. From a consistency perspective there's > an idiomatic angle to some sort of "/proc/kheaders.gz". I'm not arguing against providing the headers in some format, I think that's a good idea. On similarities, there are some but there are also substantial differences in the use model. For the config file, the main use cases are: - Checking to make sure that the running kernel has a particular set of config options set or cleared. - Ease of cloning the config of a running kernel when building a new one. The file format is just a plain text file, even if compressed. No real internal structure to consider. Both of the above uses are relatively rare (well, the first might be done in some startup scripts, etc). The kernel headers case is different. The file format is more complex (tarball, which would also include the structure of said tarball). You can't just zgrep to get some data out. Also, the way the contents is used is different, in that it will be needed by runtime tools that build and load eBPF programs. For the build to always be known to be against the running headers, every build would likely need to decompress and stage said tarball independently and not rely on previous state. If that's needed, why not just provide it once in the right format and avoid people building userspace solutions in several different ways to do the same thing? > In some offline discussions I was also told that squashfs (I'm no expert > of it) required special user-space tools and had some security issues. I'm unaware of what the security issues are, and there's indeed a GPLv2 tool needed to construct the filesystem. The latter can be solved, the former I don't know enough about to have an opinion. Anyway, see my other reply just now -- CPIO + a filesystem view, and providing said cpio archive in debugfs for those who want to copy it off themselves might be something that fits everybody. -Olof