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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 BBF097D04D for ; Mon, 15 Apr 2019 13:52:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727399AbfDONwx (ORCPT ); Mon, 15 Apr 2019 09:52:53 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:33106 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726696AbfDONwx (ORCPT ); Mon, 15 Apr 2019 09:52:53 -0400 Received: by mail-pl1-f195.google.com with SMTP id t16so8617698plo.0 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=Zq+A7BqObjxzfwwkKJL9b7dxYgDtHW9tGPk7MJcJfhtzrW5wstcx9a1fspsPhGQEtD FNQFHq5oiI243muZy+cY4i6zhJcoqfAfbEEsYvZ/XPPwlXpPsSkjPvJPZ06vTK+qADve pJH97aE9tnwTY2bI3rKTwTXHmJ9FcbZNdefIb4X+2J1jfY0sPkQn0acBKiiANbprqtIH ki5SELdeiTLB1l32rl6kYwvg3CLenSLv2C+7g7MFr+9zecb8QZELvfXCACubQryIpzHe PZ6OYmZkUVa8zmalO7K7ZfH3snq3xm/pDQMTVGV12xg+hFV3og9ec65mPObZ3ImzXcQL +TAQ== X-Gm-Message-State: APjAAAXFUtnKALiha3di7hu5RrQkLDM9zNmONDXdnKPNx+SaQbivZoyv 9zoXx58EUXwsmCYL+rIhyaGY+vTFwCU= 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-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@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