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=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT 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 4EFEFC10F0E for ; Mon, 15 Apr 2019 13:52:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 127842073F for ; Mon, 15 Apr 2019 13:52:55 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=joelfernandes.org header.i=@joelfernandes.org header.b="uws0u/Ik" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727545AbfDONwx (ORCPT ); Mon, 15 Apr 2019 09:52:53 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:35870 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726102AbfDONwx (ORCPT ); Mon, 15 Apr 2019 09:52:53 -0400 Received: by mail-pl1-f193.google.com with SMTP id ck15so8618064plb.3 for ; Mon, 15 Apr 2019 06:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=H0ECi+coMQS790WnImRT1BzjbruprNFYZr4FQCCImBI=; b=uws0u/IkNDfeA2aOvTdeHGFjirw9YYE/5u5AUfvNXfVn+H6je/jHQelY8+nZrZuRYq eDzLzropG6PNgCzqtC2NsAj+zU3QiYKndfbSXySUYPqD2INxgS6JQUu2oR0IUOFOAYyA zRNv5j/L3ZUeLHToSwPIzAPQ9mUMDx9lLnoVU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=H0ECi+coMQS790WnImRT1BzjbruprNFYZr4FQCCImBI=; b=BynuvRce6Q9MD8TmQAPz6R9LjG4eFsChu7x9rnrGnp/Vhum1B38qp5XoxMtA0xrSL1 AYAfNp6wDG7qThNhCD1C6TpTYe7TLzQ3riiBrR5+xB3jPpAcjIbuDigicTZno66BUX90 WccjgX3ZrSJhP6lW+h4z0eEwbTJvtkSJYfLn1/rCkD5ih6LsJGllUTcqDAQCGi++5chr tiyajxJojJKRydLRCgUxow+OBp+FgyhLQSlSppsFAxP4o+17juagujNcBsLFmhsiDxaK iWGlsj2NtPuTdr+2Bv54GJiyUf/nulrwo/tb56K6RwmycmRbOSkmsxqJNAURUVVvpJTk h+DQ== X-Gm-Message-State: APjAAAWgY1JvwRXS8zAsbv0IPs9knHfXaGfUJt1F4ehJt6JGIoYBCWqv gzBKM7UvkTAtZiZrw3Wxs6fuXg== X-Google-Smtp-Source: APXvYqwvMuOFjHGBJpuaBzExILDLa5UZfSiK+loI/oBxsUTx19uI7c1Fo4MI8zNu5pWgfbNvNjowxg== X-Received: by 2002:a17:902:6b8b:: with SMTP id p11mr51636845plk.225.1555336371864; Mon, 15 Apr 2019 06:52:51 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id y12sm118488194pgq.64.2019.04.15.06.52.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 Apr 2019 06:52:50 -0700 (PDT) Date: Mon, 15 Apr 2019 09:52:49 -0400 From: Joel Fernandes To: "Enrico Weigelt, metux IT consult" Cc: Olof Johansson , Alexei Starovoitov , 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 Subject: Re: [PATCH v5 1/3] Provide in-kernel headers to make extending kernel easier Message-ID: <20190415135249.GA205801@google.com> References: <20190320163116.39275-1-joel@joelfernandes.org> <20190408203601.GF133872@google.com> <20190411031540.ehezr6kq7ouobpzx@ast-mbp.dhcp.thefacebook.com> <463a08cb-d1ac-b750-c699-8242c2c20fd2@metux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <463a08cb-d1ac-b750-c699-8242c2c20fd2@metux.net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 15, 2019 at 11:41:18AM +0200, Enrico Weigelt, metux IT consult wrote: [snip] > > This patch seems to have been met with a lot of responses in the tone> of "this is not an appealing solution". > > Personally, having generic helpers for putting blobs into /proc files > (like config.gz) sound appealing. But I'm not sure whether doing that > w/ kernel headers this way is a good solution. Actually, I'm even not > sure whether raw kernel headers are at all are a good way. (can't we > use compiler-generated debug info ?) We can't use compiler generated debug info for this. As discussed previously here, eBPF tools need kernel headers, DWARF and compiler debug information wont help: https://lkml.org/lkml/2019/3/11/1358 https://lkml.org/lkml/2019/3/11/1363 > > Usually what we do at times like this is that we say "Yeah, this is a> problem that should be solved, but this solution doesn't seem to be> > the right one and we would need to maintain it forever as part of the> > ABI. Let's wait until a better solution is found." With time,> sometimes > a better solution becomes obvious, or circumstances change> enough to > allow for some different approach, or someone has a new idea> from a > different perspective that solves the same problem. > ACK. For now, this is an Android-only debug tool, just needed there > because of it's unusual partitioning/deployment mechanisms - on usual > GNU/Linux distros, we just have the kheaders in the file system. > (and even on my small embedded devices, I either run the DUTs via NFS, > 9P2k, initrd, etc or just deploy kernel and headers into the filesystem) > > As Android already is in it's own universe, why can't that stuff remain > incubated there, until we have more field experience w/ it and more time > to rethink the whole idea very carefully ? Well, we follow mostly an upstream first process. > The patch is pretty small, so it's trivial cherry-pick, in case somebody > outside Android universe wants to use it. It could break very easily if things upstream change in some way, and adds a lot of maintenance burden, besides I don't see a good reason it should not be upstreamed tbh. thanks, - Joel