Hi hch.
Any specific reason why xfs uses a indirection for the Makefile?
It is planned to drop export of VERSION, PATCHLEVEL etc. from
main makefile and it is OK except for xfs due to the funny
Makefile indirection.
I suggest:
git mv fs/xfs/Makefile-linux-2.6 fs/xfs/Makefile
OK?
Sam
On Mon, Jan 09, 2006 at 05:42:14PM +0100, Sam Ravnborg wrote:
> Hi hch.
>
> Any specific reason why xfs uses a indirection for the Makefile?
> It is planned to drop export of VERSION, PATCHLEVEL etc. from
> main makefile and it is OK except for xfs due to the funny
> Makefile indirection.
>
> I suggest:
> git mv fs/xfs/Makefile-linux-2.6 fs/xfs/Makefile
I'd be all for it, but the SGI people like this layout to keep a common
fs/xfs for both 2.4 and 2.6 (with linux-2.4 and linux-2.6 subdirs respectively)
p.s. and no, I'm not official xfs maintainer and never have been, so cc set
to linux-xfs were all interested parties hang around.
On Mon, Jan 09, 2006 at 04:46:11PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 09, 2006 at 05:42:14PM +0100, Sam Ravnborg wrote:
> > Hi hch.
> >
> > Any specific reason why xfs uses a indirection for the Makefile?
> > It is planned to drop export of VERSION, PATCHLEVEL etc. from
> > main makefile and it is OK except for xfs due to the funny
> > Makefile indirection.
> >
> > I suggest:
> > git mv fs/xfs/Makefile-linux-2.6 fs/xfs/Makefile
>
> I'd be all for it, but the SGI people like this layout to keep a common
> fs/xfs for both 2.4 and 2.6 (with linux-2.4 and linux-2.6 subdirs respectively)
>
I have the following in my tree right now to make it compile.
But it looks pointless to me. All other submitters are asked to keep
backward compatibility cruft out of kernel proper - the same should
hold for xfs.
Sam
diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile
index 49e3e7e..0630339 100644
--- a/fs/xfs/Makefile
+++ b/fs/xfs/Makefile
@@ -1 +1 @@
-include $(TOPDIR)/fs/xfs/Makefile-linux-$(VERSION).$(PATCHLEVEL)
+include $(srctree)/fs/xfs/Makefile-linux-2.6
On Mon, Jan 09, 2006 at 04:46:11PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 09, 2006 at 05:42:14PM +0100, Sam Ravnborg wrote:
> > Hi hch.
> >
> > Any specific reason why xfs uses a indirection for the Makefile?
> > It is planned to drop export of VERSION, PATCHLEVEL etc. from
> > main makefile and it is OK except for xfs due to the funny
> > Makefile indirection.
> >
> > I suggest:
> > git mv fs/xfs/Makefile-linux-2.6 fs/xfs/Makefile
>
> I'd be all for it, but the SGI people like this layout to keep a common
> fs/xfs for both 2.4 and 2.6 (with linux-2.4 and linux-2.6 subdirs respectively)
>
> p.s. and no, I'm not official xfs maintainer and never have been, so cc set
> to linux-xfs were all interested parties hang around.
Following is what I have committed in my tree to avod using the now
un-exported symbols.
Sam
diff-tree a9aa1ffaac7c8d6f093bb8f7cdeea761a5e25f53 (from 0d20babd86b40fa5ac55d9ebf31d05f6f7082161)
Author: Sam Ravnborg <[email protected]>
Date: Mon Jan 9 20:48:03 2006 +0100
kbuild/xfs: introduce fs/xfs/Kbuild
In kbuild the file named 'Kbuild' has precedence over the file named
Makefile. Utilise a file named Kbuild to include the 2.6 Makefile for xfs
- since the xfs people likes to keep their arch specific Makefiles separate.
With this patch xfs does no longer rely on the KERNELRELEASE components to be global.
Signed-off-by: Sam Ravnborg <[email protected]>
diff --git a/fs/xfs/Kbuild b/fs/xfs/Kbuild
new file mode 100644
index 0000000..2566e96
--- /dev/null
+++ b/fs/xfs/Kbuild
@@ -0,0 +1,6 @@
+#
+# The xfs people like to share Makefile with 2.6 and 2.4.
+# Utilise file named Kbuild file which has precedence over Makefile.
+#
+
+include $(srctree)/$(obj)/Makefile-linux-2.6
Christoph Hellwig wrote:
> On Mon, Jan 09, 2006 at 05:42:14PM +0100, Sam Ravnborg wrote:
>
>>Hi hch.
>>
>>Any specific reason why xfs uses a indirection for the Makefile?
>>It is planned to drop export of VERSION, PATCHLEVEL etc. from
>>main makefile and it is OK except for xfs due to the funny
>>Makefile indirection.
>>
>>I suggest:
>>git mv fs/xfs/Makefile-linux-2.6 fs/xfs/Makefile
>
>
> I'd be all for it, but the SGI people like this layout to keep a common
> fs/xfs for both 2.4 and 2.6 (with linux-2.4 and linux-2.6 subdirs respectively)
>
> p.s. and no, I'm not official xfs maintainer and never have been, so cc set
> to linux-xfs were all interested parties hang around.
>
Yep, our internal tree has both linux-2.4/ and linux-2.6/ subdirs, so this is
handy internal to sgi. But I don't have a big problem with the kernel.org code
losing the indirection, even if we keep it here. I'd check with Nathan first
though, because he'd have to work around that difference when he pushes code out.
Out of curiosity, what's the reason to drop VERSION & PATCHLEVEL... seems handy
if you have a common body of code that needs to build for various kernels, with
various Makefiles to suit. As above. :)
Thanks,
-Eric
> +#
> +# The xfs people like to share Makefile with 2.6 and 2.4.
> +# Utilise file named Kbuild file which has precedence over Makefile.
> +#
> +
> +include $(srctree)/$(obj)/Makefile-linux-2.6
What about just putting the content of the current Makefile-linux-2.6
into the Kbuild file directly?
On Mon, Jan 09, 2006 at 09:05:40PM +0000, Christoph Hellwig wrote:
> > +#
> > +# The xfs people like to share Makefile with 2.6 and 2.4.
> > +# Utilise file named Kbuild file which has precedence over Makefile.
> > +#
> > +
> > +include $(srctree)/$(obj)/Makefile-linux-2.6
>
> What about just putting the content of the current Makefile-linux-2.6
> into the Kbuild file directly?
People do not expect this - since the Kbuild filename is not used expect in
the top-level directory.
So as a principle of minimum suprise I left the old Makefile as-is,
and introduced the new Kbuild file.
If xfs people likes it different then they can change it anytime.
If I one day start my little "kbuild file parser to a single makefile" project
it may be the day where we do the transition.
Sam
On Mon, Jan 09, 2006 at 03:03:57PM -0600, Eric Sandeen wrote:
> Out of curiosity, what's the reason to drop VERSION & PATCHLEVEL... seems
> handy if you have a common body of code that needs to build for various
> kernels, with various Makefiles to suit. As above. :)
The kernel is supposed to hold the code for the kernel - not a lot of
backward compatibiliy cruft.
In many places they were used to define KERNELRELEASE - but wrongly
since definition of KERNELRELEASE has changed.
Sam
Sam Ravnborg wrote:
> On Mon, Jan 09, 2006 at 03:03:57PM -0600, Eric Sandeen wrote:
>
>
>>Out of curiosity, what's the reason to drop VERSION & PATCHLEVEL... seems
>>handy if you have a common body of code that needs to build for various
>>kernels, with various Makefiles to suit. As above. :)
>
> The kernel is supposed to hold the code for the kernel - not a lot of
> backward compatibiliy cruft.
Understood, and it makes sense to yank that compat cruft from kernel.org codebases.
But it seems useful for projects outside the kernel which would like to know
which kernel they are building against, as far as the build system goes. I've
seen a few drivers out there that try to keep building for both 2.4 & 2.6.
I guess for 2.4 & 2.6, the same can be accomplished by using Makefile and
Kbuild for 2.4 and 2.6....
Maybe you can export it only if KBUILD_EXTMOD is set :)
Thanks,
-Eric
On Mon, Jan 09, 2006 at 03:23:39PM -0600, Eric Sandeen wrote:
> codebases.
>
> But it seems useful for projects outside the kernel which would like to
> know which kernel they are building against, as far as the build system
> goes. I've seen a few drivers out there that try to keep building for both
> 2.4 & 2.6.
>
> I guess for 2.4 & 2.6, the same can be accomplished by using Makefile and
> Kbuild for 2.4 and 2.6....
Good point. External modules slipped my mind when I did this change.
We have today:
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 15
EXTRAVERSION =
EXTRAVERSION will soon become -rc1
No sane driver will check for more than VERISON, PATCHLEVEL, SUBLEVEL.
xfs for once only used VERSION, PATCHLEVEL.
googling a little gave lot's of very ugly examples how it can be done
using grep, perl etc. So there is a legitim need for the variable
anyway.
So I will re-export VERISON, PATCHLEVEL, SUBLEVEL.
Sam
It'd be nice to fix this:
bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o
SPLIT include/linux/autoconf.h -> include/config/*
SHIPPED scripts/genksyms/lex.c
SHIPPED scripts/genksyms/parse.h
SHIPPED scripts/genksyms/keywords.c
HOSTCC scripts/genksyms/lex.o
SHIPPED scripts/genksyms/parse.c
HOSTCC scripts/genksyms/parse.o
HOSTLD scripts/genksyms/genksyms
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/modpost.o
HOSTLD scripts/mod/modpost
scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No such file or directory
make[1]: *** No rule to make target `/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop.
make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2
Andrew Morton wrote:
> It'd be nice to fix this:
>
> bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o
> SPLIT include/linux/autoconf.h -> include/config/*
> SHIPPED scripts/genksyms/lex.c
> SHIPPED scripts/genksyms/parse.h
> SHIPPED scripts/genksyms/keywords.c
> HOSTCC scripts/genksyms/lex.o
> SHIPPED scripts/genksyms/parse.c
> HOSTCC scripts/genksyms/parse.o
> HOSTLD scripts/genksyms/genksyms
> HOSTCC scripts/mod/file2alias.o
> HOSTCC scripts/mod/modpost.o
> HOSTLD scripts/mod/modpost
> scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No such file or directory
> make[1]: *** No rule to make target `/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop.
> make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2
I'll see what I can do to fix this up and a couple of other kbuild issues I've
run into recently.
Thanks,
-Eric
Andrew Morton wrote:
> It'd be nice to fix this:
>
> bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o
> SPLIT include/linux/autoconf.h -> include/config/*
> SHIPPED scripts/genksyms/lex.c
> SHIPPED scripts/genksyms/parse.h
> SHIPPED scripts/genksyms/keywords.c
> HOSTCC scripts/genksyms/lex.o
> SHIPPED scripts/genksyms/parse.c
> HOSTCC scripts/genksyms/parse.o
> HOSTLD scripts/genksyms/genksyms
> HOSTCC scripts/mod/file2alias.o
> HOSTCC scripts/mod/modpost.o
> HOSTLD scripts/mod/modpost
> scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No such file or directory
> make[1]: *** No rule to make target `/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop.
> make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2
Hm, maybe Sam can correct me if I'm wrong, but I'm not sure that kbuild will
support more than one Makefile/Kbuild file per module; so if we have some code
in a subdirectory, I think it all needs to be driven from the parent
directory's Makefile... and then the above doesn't work.
Sam, is there any way to make this work with some code for the module in a
subdirectory?
Thanks,
-Eric
On Mon, Jan 09, 2006 at 11:45:32PM -0800, Andrew Morton wrote:
>
> It'd be nice to fix this:
>
> bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o
> SPLIT include/linux/autoconf.h -> include/config/*
> SHIPPED scripts/genksyms/lex.c
> SHIPPED scripts/genksyms/parse.h
> SHIPPED scripts/genksyms/keywords.c
> HOSTCC scripts/genksyms/lex.o
> SHIPPED scripts/genksyms/parse.c
> HOSTCC scripts/genksyms/parse.o
> HOSTLD scripts/genksyms/genksyms
> HOSTCC scripts/mod/file2alias.o
> HOSTCC scripts/mod/modpost.o
> HOSTLD scripts/mod/modpost
> scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No such file or directory
> make[1]: *** No rule to make target `/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop.
> make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2
xfs as one of the very few users in the kernel has split up .o files in
several directories. And kbuild does not have support for specifying
that is shall link to a .o file that is being build in a sub-directory.
This is in general noe encouraged for the kernel - it is not common
practice. And therefore not something I have planned to implement.
If there is a general consensus that we like to have this then it is
doable, but it will uglify scripts/Makefile.lib even more.
For xfs this is 37 .o files that are build in three directories.
The easy fix would be to move the files to stay just under the xfs/
directory like all others - but xfs people prefer not to do so to stay
compatible with their external source tree.
Sam
On Tue, Jan 10, 2006 at 10:34:42AM -0600, Eric Sandeen wrote:
> Andrew Morton wrote:
> >It'd be nice to fix this:
> >
> >bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o
> > SPLIT include/linux/autoconf.h -> include/config/*
> > SHIPPED scripts/genksyms/lex.c
> > SHIPPED scripts/genksyms/parse.h
> > SHIPPED scripts/genksyms/keywords.c
> > HOSTCC scripts/genksyms/lex.o
> > SHIPPED scripts/genksyms/parse.c
> > HOSTCC scripts/genksyms/parse.o
> > HOSTLD scripts/genksyms/genksyms
> > HOSTCC scripts/mod/file2alias.o
> > HOSTCC scripts/mod/modpost.o
> > HOSTLD scripts/mod/modpost
> >scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No
> >such file or directory
> >make[1]: *** No rule to make target
> >`/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop.
> >make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2
>
> Hm, maybe Sam can correct me if I'm wrong, but I'm not sure that kbuild
> will support more than one Makefile/Kbuild file per module; so if we have
> some code in a subdirectory, I think it all needs to be driven from the
> parent directory's Makefile... and then the above doesn't work.
>
> Sam, is there any way to make this work with some code for the module in a
> subdirectory?
Hi Eric - I covered this in my reply to Andrew.
The short version - no, and it is not planned.
Sam
On Tue, Jan 10, 2006 at 10:34:42AM -0600, Eric Sandeen wrote:
> Andrew Morton wrote:
> >It'd be nice to fix this:
> >
> >bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o
> > SPLIT include/linux/autoconf.h -> include/config/*
> > SHIPPED scripts/genksyms/lex.c
> > SHIPPED scripts/genksyms/parse.h
> > SHIPPED scripts/genksyms/keywords.c
> > HOSTCC scripts/genksyms/lex.o
> > SHIPPED scripts/genksyms/parse.c
> > HOSTCC scripts/genksyms/parse.o
> > HOSTLD scripts/genksyms/genksyms
> > HOSTCC scripts/mod/file2alias.o
> > HOSTCC scripts/mod/modpost.o
> > HOSTLD scripts/mod/modpost
> >scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No
> >such file or directory
> >make[1]: *** No rule to make target
> >`/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop.
> >make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2
>
> Hm, maybe Sam can correct me if I'm wrong, but I'm not sure that kbuild
> will support more than one Makefile/Kbuild file per module; so if we have
> some code in a subdirectory, I think it all needs to be driven from the
> parent directory's Makefile... and then the above doesn't work.
>
> Sam, is there any way to make this work with some code for the module in a
> subdirectory?
Hi Eric.
I forgot to point out one ugly solution for this.
You can include a dummy Kbuild (Makefile) in each directory to support
this. I recall that reiser4 had similar question and this was the
solution I pointed out for them too.
No - I am not in favour of it. But for local development it could make
sense.
So it may solve the "Eric" part of it, but not the "Andrew" part of it
since these file will never get in the mainstream kernel (hopefully).
Sam
Sam Ravnborg wrote:
>>Sam, is there any way to make this work with some code for the module in a
>>subdirectory?
>
>
> Hi Eric.
> I forgot to point out one ugly solution for this.
> You can include a dummy Kbuild (Makefile) in each directory to support
> this. I recall that reiser4 had similar question and this was the
> solution I pointed out for them too.
> No - I am not in favour of it. But for local development it could make
> sense.
> So it may solve the "Eric" part of it, but not the "Andrew" part of it
> since these file will never get in the mainstream kernel (hopefully).
>
> Sam
Thanks, Sam - I'd considered that, too. We may do it locally.
-Eric