Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1006762imj; Thu, 7 Feb 2019 15:51:13 -0800 (PST) X-Google-Smtp-Source: AHgI3IZLijrzWJX4IP6aUAcyF0zeYME3f4v+UcvxNMfIX7g7OhahXEJx7kTUWgHeu9e5mclc4j7z X-Received: by 2002:aa7:84c7:: with SMTP id x7mr10502564pfn.180.1549583473164; Thu, 07 Feb 2019 15:51:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549583473; cv=none; d=google.com; s=arc-20160816; b=I3JgV7cQhSBHRcYQ4WltnlfVZecQ5IDOFcfE7GyzJkj8VHUfW1rv2DXmLWaIQwBMnr ONkKbctlIiuwnq/LzT10TgVLdfnU3McPQC9NQoi9oRsvGmlA+AIyJ0egalLWzJw5Xd5/ i8ygX6CT1SFGnTG5KZ3gJ7YcSsELYPetJaMe6iE51Anz2v3TO752SONOlNuPFQWShc0f /Dyz0TKuy7yGredURZKUZKDrJ8kBh3i+PpuUXE1ikU5hZvQZGxhlc39Lz990bpJE9kdG BpbY9zsbb9n0Tl8wSSIYkc7NuADpnqcuIPScItvw+MQ1ODzTWjBm2E8vI1LzjixZ2Dae DBdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=0BrNJDgyuUPmsTSYBD/fWvO3TcCh91LFPA2Pocg8ApI=; b=H9Hadid7m8EUkckgDisccDKYoj7DFqsPEgUs+kNHHrwtOt4LiANgtHRH0b2KD3V/o8 LZxwyJ33H6H6hBr1R0Nj3bjNY9QqfaXpzDZ4yEeWSvJGS25CC3R0howzdye75SxRFaln Ed8k5ZdwO7W2ZF7zqdwFgAAUwog5f+/QkFNohytPkeTwFdzNwT8n3NUwpce6YITgGfTC j1JxMp6Mi8vDmOVqtehWBEA8qnRDS25+TFRoAucLajeBHtzRv0ZMPrZg2gm3u4fnIUnS CI4j9Ncwsn5QshICrqCBu9TixLCQu//Me+YXFQ9PvcbHd4NMO5aGX93njDDsWCnPaKE5 Gjvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j10si381251plk.238.2019.02.07.15.50.56; Thu, 07 Feb 2019 15:51:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726896AbfBGXus (ORCPT + 99 others); Thu, 7 Feb 2019 18:50:48 -0500 Received: from mail.kernel.org ([198.145.29.99]:47902 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726650AbfBGXuq (ORCPT ); Thu, 7 Feb 2019 18:50:46 -0500 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A4EEE2173B; Thu, 7 Feb 2019 23:50:43 +0000 (UTC) Date: Thu, 7 Feb 2019 18:50:42 -0500 From: Steven Rostedt To: Joel Fernandes Cc: linux-kernel@vger.kernel.org, Alexandre Torgue , Andrew Morton , ast@kernel.org, atishp04@gmail.com, dancol@google.com, Dan Williams , gregkh@linuxfoundation.org, Ingo Molnar , Jonathan Corbet , karim.yaghmour@opersys.com, Kees Cook , kernel-team@android.com, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, Manoj Rao , Masahiro Yamada , Mathieu Desnoyers , Maxime Coquelin , paulmck@linux.vnet.ibm.com, "Peter Zijlstra (Intel)" , rdunlap@infradead.org, Shuah Khan , Thomas Gleixner , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , yhs@fb.com Subject: Re: [PATCH 1/2] Provide in-kernel headers for making it easy to extend the kernel Message-ID: <20190207185042.76c7d68f@gandalf.local.home> In-Reply-To: <20190207233902.GA193818@google.com> References: <20190207211102.154634-1-joel@joelfernandes.org> <20190207175239.0607f5eb@gandalf.local.home> <20190207233902.GA193818@google.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 Feb 2019 18:39:02 -0500 Joel Fernandes wrote: > > > + > > > +spath="$(dirname "$(readlink -f "$0")")" > > > + > > > +rm -rf $1.tmp > > > +mkdir $1.tmp > > > + > > > +for f in "${@:2}"; > > > + do find "$f" ! -name "*.c" ! -name "*.o" ! -name "*.cmd" ! -name ".*"; > > > > I wonder if it is a good idea to pick all files in the directories > > defined in ikh_file_list, and not just explicitly list what we want, > > with a '*.h' and such? > > I also need few files in the archive that are not .h, these don't take up > much space but are needed to make an out-of-tree kernel module build succeed. > > One of my goals with this was to make a self-contained module that could be > loaded to build other modules. Majority of the files are kernel headers, but > some are not, such as Module.symvers and other scripts. Then one can run > systemtap on Android which can be made to build modules using the embedded > headers. Have you audited what it picks up? My main concern is that we start adding files that are not necessary or just simply added in the directory that are not needed for this. > > > > +done | cpio -pd $1.tmp > > > + > > > +for f in $(find $1.tmp); do > > > + $spath/strip-comments.pl $f > > > +done > > > + > > > +tar -Jcf $1 -C $1.tmp/ . > /dev/null > > > + > > > +rm -rf $1.tmp > > > diff --git a/scripts/strip-comments.pl b/scripts/strip-comments.pl > > > new file mode 100755 > > > index 000000000000..f8ada87c5802 > > > --- /dev/null > > > +++ b/scripts/strip-comments.pl > > > @@ -0,0 +1,8 @@ > > > +#!/usr/bin/perl -pi > > > +# SPDX-License-Identifier: GPL-2.0 > > > + > > > +# This script removes /**/ comments from a file, unless such comments > > > +# contain "SPDX". It is used when building compressed in-kernel headers. > > > + > > > +BEGIN {undef $/;} > > > +s/\/\*((?!SPDX).)*?\*\///smg; > > > > Hmm, I'm also wondering if we could us the C pre-processor for the > > stripping of everything from the header file. We would then even get > > the header files only having what is necessary for the running kernel. > > I thought about this too. An issue with that is it is going to be really slow > due to the large number of headers. The other is, I think it will actually > make the headers bigger and take up more space - because all the include > directives will also be expanded and have more duplication. Let me know if I > missed something though. > Good point about the duplication. I was mostly thinking of getting rid of "#ifdef" blocks. BTW, these comments are more of a "have you thought about this" and not really action comments. -- Steve