On Fri, Nov 23, 2018 at 5:04 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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: ================= WARNING ================ > > Makefile:190: 'SUBDIRS' will be removed after Linux 5.3 > > Makefile:191: Please use 'M=' or 'KBUILD_EXTMOD' instead > > Makefile:192: ========================================== > > > > Signed-off-by: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> > > No, please don't do this. This is effectively a kernel←→user 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 := mymod.o' > Makefile > make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` It has been *ages* since the external module build was improved in the current way. Since then, M=<...> 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 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/