From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f169.google.com ([209.85.128.169]:34860 "EHLO mail-wr0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752484AbdC0JpS (ORCPT ); Mon, 27 Mar 2017 05:45:18 -0400 Received: by mail-wr0-f169.google.com with SMTP id u1so47719958wra.2 for ; Mon, 27 Mar 2017 02:45:07 -0700 (PDT) Reply-To: nicolas.dichtel@6wind.com Subject: Re: [PATCH v10 00/11] uapi: export all headers under uapi directories References: <1489496093-15315-1-git-send-email-nicolas.dichtel@6wind.com> <365519b5-d69e-34b7-fa2f-f11b8fabe69f@6wind.com> From: Nicolas Dichtel Message-ID: Date: Mon, 27 Mar 2017 11:45:02 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Masahiro Yamada Cc: Arnd Bergmann , Michal Marek , Linux Kbuild mailing list , Linux Kernel Mailing List , linux-arch@vger.kernel.org, David Airlie , "David S. Miller" , Russell King , bp@alien8.de, slash.tmp@free.fr, Daniel Vetter , rmk+kernel@armlinux.org.uk, msalter@redhat.com, jengelh@inai.de, hch@infradead.org, Tobias Klauser , mpe@ellerman.id.au, Ingo Molnar , Thomas Gleixner , "Dmitry V. Levin" , Herbert Xu , linux-rdma@vger.kernel.org Message-ID: <20170327094502.niaSN83gNRV1EefBO6ogKzl0KXDFSsj2oNTux-c0Rws@z> Hi Masahiro, Le 27/03/2017 à 07:26, Masahiro Yamada a écrit : > Hi Nocolas, > > > 2017-03-24 18:03 GMT+09:00 Nicolas Dichtel : [snip] > > > As a whole, this series is amazing. Thanks for your great work! Thank you. And thank you for taking time to review it. > > > I added some comments, but they are trivial. > > > > > I wanted to leave comments/questions on 10/11, > but I could not find 10/11 in my mailbox. I do not know why. Note that you can download the mail from the kbuild patchwork, open it with your email client and do a reply ;-) > > > I am leaving comments on the cover-letter, > the following are related to 10/11. > > > > [1] > >> mandatory-y += $(foreach hdr,$(opt-header), \ >> $(if \ >> $(wildcard \ >> $(srctree)/arch/$(SRCARCH)/include/uapi/asm/$(hdr) \ >> $(srctree)/arch/$(SRCARCH)/include/asm/$(hdr) \ >> ), \ >> $(hdr) \ >> )) > > What is this actually checking? > > If ARCH has its own (uapi/)asm/{kvm.h,kvm_para.h,a.out.h}, > they are added to mandatory-y, then they are checked if they exist. > But, we know they exist. Yes, you're right. With english words : 'those files are mandatory only if they exist', thus they are not mandatory at all :) > > > This check reminds us only when we added asm/*.h > but forgot to add uapi/asm/*.h > > $(srctree)/arch/$(SRCARCH)/include/uapi/asm/$(hdr) seems unneeded at least. > (perhaps, the whole hunk might be unneeded.) I think we can remove the whole hunk (see also [2]). > > > > [2] > >> ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/a.out.h \ >> $(srctree)/arch/$(SRCARCH)/include/asm/a.out.h),) >> header-n += a.out.h >> endif >> >> ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/kvm.h \ >> $(srctree)/arch/$(SRCARCH)/include/asm/kvm.h),) >> header-n += kvm.h >> endif >> >> ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/uapi/asm/kvm_para.h \ >> $(srctree)/arch/$(SRCARCH)/include/asm/kvm_para.h),) >> header-n += kvm_para.h >> endif > > This series intends all headers are exported from uapi/, correct? > Do we still need to check $(srctree)/arch/$(SRCARCH)/include/asm/*.h ? > (related to [1]) No you're right, uapi/asm/*.h is enough. Those files should be exported only if the uapi/asm/ counterpart exists. > > > > [3] > >> --- 7.1 header-n >> >> header-n is essentially used by include/uapi/linux/Kbuild to avoid >> exporting specific headers (e.g. kvm.h) on architectures that do not >> support it. It should be avoided as much as possible. > > > Going forward, header-y will be never used > because uapi/ is exported by default. > > So, I wonder if we could rename this into something clearer. > > Kbuild supports "no-clean-files". > (Please see ./Kbuild for its usage) > I guess this notation seems clearer > when we want to negate the default behavior. > > Can you consider "no-export", "no-export-files", "no-export-headers" > or whatever you like? No problem, let's use no-export-headers. Thank you, Nicolas