Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3221283imu; Sat, 24 Nov 2018 00:26:16 -0800 (PST) X-Google-Smtp-Source: AFSGD/WjYDeCAbru7xchI+1muvTwFd8lc1VjXLkFt/Aq4VTwl45j9GZBb3EjAuLzfRbIQM3vv9fM X-Received: by 2002:a63:295:: with SMTP id 143mr16549038pgc.362.1543047976078; Sat, 24 Nov 2018 00:26:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543047976; cv=none; d=google.com; s=arc-20160816; b=QdNjCNl8D10jIdXFD5d1qG1ZiHAcPKdOM8dT8+orgxGNWUux3oy/TiK5H8aWp34b/f Fo42vJG9OtmxnS2T5BtREu9uYjRzehSHWHGSnxps21FVyvDwBhMKQhy9MV1pgcZtWDYu 5x/AJCqao0xdKWFux4Hcy2thicswP59dgH22J/1eF2k9a7IobabRIrEcc5Sh7ynowe2Z UlfNmWTqahTbbWTBr6Y3cBZMi3t+oadnSncnwUwgTSX2cmGBYafQlX5L6QDs+V11zB3m s4i1hKDa3zLOng9snkxswa6u3t7rYpNWAU9G7YPpBb31fxyvE7Fl28X/jCARc+Z2LZ87 HDbA== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature:dkim-filter; bh=ty6bBoM/zHS90bYYTMrdpT/s6grcZYWbFLZPt32hzpI=; b=Wx17QHxQRWerPrEX0A29U02IpaQgADXpP/p89+3bcrEZ9W/Ps8DrPm4RephRN3OnZR aKqEhCcaW9LgHzKvq2QW6IOjSmOTJ+U4dAFgXwkGoscp66ZlWAP0gQbz8QbzW91cnm59 EEY87CVIUdPGrePs/VaezTNY+urYXHhEg0B5VjTwESELE1Y8ftDsn5LVLvloU6fqWGzD fREAiUqUkcQuk0lofDB5TGfMn3T9LtsmgEHquXIGqca1up4wq9+c3oeNWge/QuwDbuLc Xwxd2cDJSW1y1E6wUHWr9oOlv361z8uZnZcu3CVKBwN8L8rC6G3jMWZPfsBIodH+cJs0 wKkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=wFHy9DiH; 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 c1si12300985plz.121.2018.11.24.00.26.01; Sat, 24 Nov 2018 00:26:16 -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; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=wFHy9DiH; 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 S2409503AbeKWVgE (ORCPT + 99 others); Fri, 23 Nov 2018 16:36:04 -0500 Received: from conssluserg-02.nifty.com ([210.131.2.81]:40273 "EHLO conssluserg-02.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390614AbeKWVgE (ORCPT ); Fri, 23 Nov 2018 16:36:04 -0500 X-Greylist: delayed 20955 seconds by postgrey-1.27 at vger.kernel.org; Fri, 23 Nov 2018 16:36:02 EST Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (authenticated) by conssluserg-02.nifty.com with ESMTP id wANAq34Z026467; Fri, 23 Nov 2018 19:52:03 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-02.nifty.com wANAq34Z026467 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1542970324; bh=ty6bBoM/zHS90bYYTMrdpT/s6grcZYWbFLZPt32hzpI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=wFHy9DiHLIWcW6hcnueeA+U9g2wHl0/DwuhWKY8NSvuX0JQsNdtV0T/+/KcbcRgCi w6H4beGmjd2654T7QKvHmmC1/JjazdzZFJv18L/QC7nVhnGZuY2CVVWFdyiGsdSiZj l+4VQzvvf3DlHkpVbG09uNcrsTW73bQKhLMn4I3dLukmlWHRthp9kds4fyF9/Ym2qG +MprhMmPMJ6S4mG6z8U0oPX8ZUMlM+kZt0jVV3m/KqyBuHPe8d/T8YInnQ9FDrKcL0 +iwryTT8uGT5MmQ6SwyH9TRHFISxUz8iwCEvQm5dP9LT2ggydtWsonzpHNp5duExqy od7DgwczBQeoQ== X-Nifty-SrcIP: [209.85.217.50] Received: by mail-vs1-f50.google.com with SMTP id e7so6926048vsc.2; Fri, 23 Nov 2018 02:52:03 -0800 (PST) X-Gm-Message-State: AGRZ1gIvz9jJJBJiqwz2mD1lRfa8SDruO+D0lwz1Gi9qk2aPrXj4fCaD fS94pBa/7bEKXlOJ48riDqwMLbIrbX8DonFmKBU= X-Received: by 2002:a67:f1d6:: with SMTP id v22mr6201388vsm.181.1542970322414; Fri, 23 Nov 2018 02:52:02 -0800 (PST) MIME-Version: 1.0 References: <1542726258-8418-1-git-send-email-yamada.masahiro@socionext.com> <87d7d90bf8779a997b17c917680995abc455cf11.camel@infradead.org> In-Reply-To: <87d7d90bf8779a997b17c917680995abc455cf11.camel@infradead.org> From: Masahiro Yamada Date: Fri, 23 Nov 2018 19:51:26 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] kbuild: announce removal of SUBDIRS if used To: David Woodhouse Cc: Linux Kbuild mailing list , Sam Ravnborg , =?UTF-8?B?TWFyZWsgVmHFoXV0?= , Guenter Roeck , linux-watchdog@vger.kernel.org, wim@linux-watchdog.org, "open list:DOCUMENTATION" , Jim Cromie , Jonathan Corbet , Linux Kernel Mailing List , Michal Marek , Brian Norris , Richard Weinberger , linux-mtd , Boris Brezillon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 23, 2018 at 5:04 PM David Woodhouse wrote= : > > On Wed, 2018-11-21 at 00:04 +0900, Masahiro Yamada wrote: > > SUBDIRS has been kept as a backward compatibility since > > commit ("[PATCH] kbuild: external module support") in 2002. > > > > We do not need multiple ways to do the same thing, so I will remove > > SUBDIRS after the Linux 5.3 release. I cleaned up in-tree code, and > > updated the document so that nobody would try to use it. > > > > Meanwhile, display the following warning if SUBDIRS is used. > > > > Makefile:189: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WARNI= NG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Makefile:190: 'SUBDIRS' will be removed after Linux 5.3 > > Makefile:191: Please use 'M=3D' or 'KBUILD_EXTMOD' instead > > Makefile:192: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Signed-off-by: Masahiro Yamada > > No, please don't do this. This is effectively a kernel=E2=86=90=E2=86=92u= ser ABI. External modules are just downstream kernel code. There is no guarantee for eternal backward compatibility. Actually, kernel headers and APIs are always changing. We are not allowed to break the upstream code during API migration, but we do not care about external modules. If you want to compile external modules with a new version of the kernel, you need to adjust various parts of the code anyway. Is it a problem to ask one-liner fix in a build script? > The instructions for building a kernel module have been this, for > *ages*: > > echo 'obj-m :=3D mymod.o' > Makefile > make -C /lib/modules/`uname -r`/build SUBDIRS=3D`pwd` It has been *ages* since the external module build was improved in the current way. Since then, M=3D<...> is a preferred way over SUBDIRS. This case is even nicer. I set a one-year grace period with a clear warning message. > People have muscle memory, they have it encoded into various of their > own makefiles and build scripts. Please don't make it stop working > unless there's actually a really good reason to do so. Dumping old code is a good reason. -- Best Regards Masahiro Yamada