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=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 E0691C10F11 for ; Wed, 10 Apr 2019 19:19:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B5E9420820 for ; Wed, 10 Apr 2019 19:19:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726562AbfDJTTf (ORCPT ); Wed, 10 Apr 2019 15:19:35 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:36790 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726073AbfDJTTf (ORCPT ); Wed, 10 Apr 2019 15:19:35 -0400 Received: by mail-qt1-f196.google.com with SMTP id s15so4287938qtn.3; Wed, 10 Apr 2019 12:19:34 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yg1CRWpDLdkT8DcNZ4/1Kt/Rhj0AKjem9XJsrZeWYb4=; b=lauKN18AGDfCEExEDyPVOa6Uh3GT+LQZQj/aeAOz7VFiWFFaOL0w+MUEUCBJHzGgil w/xQGaxhbSpedYNvNYUqkJomuVauywfUYmzsV0H4jqAOxB6mYU6kBaFMIK6m7QT+tU78 IJeNJe4AQa/hR5w5gHAgvH6tZu19NVa2RXXDOmVjhajGlbpg0cl/+uJAzn9+2WsGfCuS AqCsmmvyJqsRTwIo4XflWg9WkFHZ5jsMLbZP3LrM2cItIZCNn0WaSdP/zq687cSQmMfN SCVwL0isVUQdNVZRjtTA4dS8NFJDFCUXpR+i5RICbk5/Ft+NE2Tb01XnJa+yfEBOrQAY yz2w== X-Gm-Message-State: APjAAAUFzi5zPHKeWxYsd92EddTdEVlxTtmeM2DbmhBChPNb6vgsAUhU tYQrcPHQlnCPfmnsHMUkC3xiL2vjL9WS9wd9Yhk= X-Google-Smtp-Source: APXvYqziMS9Y6MH6ktb8d7CS4J0XVAajtu4pUUPQPiejmRWed2wG2wYZO8+c+KHJQJataW3FJ+L3UHv8L+Bm/YeJX5o= X-Received: by 2002:a0c:9dcb:: with SMTP id p11mr36568433qvf.28.1554923973662; Wed, 10 Apr 2019 12:19:33 -0700 (PDT) MIME-Version: 1.0 References: <20190320163116.39275-1-joel@joelfernandes.org> <20190408203601.GF133872@google.com> In-Reply-To: From: Arnd Bergmann Date: Wed, 10 Apr 2019 21:19:17 +0200 Message-ID: Subject: Re: [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier To: Olof Johansson 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 , Karim Yaghmour , 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-trace-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-trace-devel@vger.kernel.org On Wed, Apr 10, 2019 at 5:09 PM Olof Johansson wrote: > > As far as format goes; there's clear precedent on cpio being used and > supported; we already have build time requirements on the userspace > tools with some options. Using tar would actually be a new dependency > even if it is a common tool to have installed. With a self-populating > FS, there's no new tool requirements on the runtime side either. The decision between tar and cpio directly follows from whether the headers are uncompressed in kernel space or in user space: - we use cpio for initramfs because unpacking cpio in C code is fairly simple, while unpacking tar is not (see the wikipedia page on tar). If we were to unpack it from the kernel, the initramfs code could be trivially reused. - nobody sane uses cpio in user space, since tar is already present almost everywhere, while cpio is rather obscure in comparison. Arnd