Re-reading several makefiles,
- fs/proc/Makefile builds nommu.o and task_nommu.o unconditionally.
- mm/Makeilfe builds nommu.o unconditionally.
So I change my mind and stop adding ifndef CONFIG_MMU.
Oops! I was wrong. Sorry.
Please ignore my previous mail.
J. R. Okajima
--
To
Ian Campbell:
In file included from /=ABPKGBUILDDIR=BB/include/linux/mm.h:23:0,
from /=ABPKGBUILDDIR=BB/include/linux/pid_namespace.h:6,
from /=ABPKGBUILDDIR=BB/include/linux/ptrace.h:9,
from
Ian Campbell:
The following patch which does what I think you are suggesting works OK
for me too.
Thanks for the patch.
#ifndef CONFIG_MMU was less important since the built kernel doesn't
contain the functions defined in the header as long as they are unused.
But by moving them into a source
Ian Campbell:
#ifndef CONFIG_MMU was less important since the built kernel doesn't
contain the functions defined in the header as long as they are unused.
But by moving them into a source file, the built kernel will contain
them. So ifndef CONFIG_MMU is necessary this time.
Yes, good
Hello Ian,
Ian Campbell:
This include is added by aufs3-mmap.patch but causes circular
dependencies on arm64 as seen with the Debian kernel packages in
:::
According to http://article.gmane.org/gmane.linux.ports.arm.kernel/342042
The added mm.h-fs.h looks like a mistake, it should
Thorsten Glaser:
This doesn=E2=80=99t really differ from what I sent last,
does it?
I am afraid you may not understand the important parts.
- the order of the definition and sched.h.
- no undef.
+#ifdef __KERNEL__
Hrm. Is this needed?
Indeed necessary since aufs_name.h is exported to
Thorsten Glaser:
Hrm, okay. I=E2=80=99ll try your patch then, once we get that register_cpu
issue solved too. I=E2=80=99ll get back to you with test results.
Hold it please.
I am going to make more changes. So it is better to git-pull and test
the aufs GIT repository.
It will be released in
From: J. R. Okajima hooano...@yahoo.co.jp
By the previous commit,
8dc5387 2012-01-03 aufs: bugfix, headers 1/2, where the pr_fmt macro definition
several header file inclusion in other files became unnecessary.
Signed-off-by: J. R. Okajima hooano...@yahoo.co.jp
---
fs/aufs/branch.c |1 -
From: J. R. Okajima hooano...@yahoo.co.jp
The pr_fmt macro is defined in fs/aufs/Makefile and it refers to the
AUFS_NAME macro, which caused a compilation error in m68k architecture.
Also it refers to the current macro which will be a problem too.
See-also:
From: J. R. Okajima hooano...@yahoo.co.jp
Thorsten Glaser:
Please send patches that _should_ apply against what=E2=80=99s in Debian.
I don=E2=80=99t have time to play the merge game at the moment.
Which version of debian?
As you might know, the aufs module in the debian stable squeeze is out
Geert Uytterhoeven:
If the Makefile refers to the macro, perhaps the Makefile should
define it, and pass it with -D?
??
Instead of defining it in Makefile, -imacros linux/aufs_name.h is
added. Or do you mean -imacros is useless?
J. R. Okajima
--
To UNSUBSCRIBE, email to
Thorsten Glaser:
It introduces a new separated file include/linux/aufs_name.h.
Isn=E2=80=99t that a bit overkill?
Hmm, I may have to agree with that.
Honestly speaking, I don't like this approach.
But embedding (expanding) AUFS_NAME is worse for me.
If the Makefile refers to the macro,
Ben Hutchings:
Why, how often do you expect to change AUFS_NAME?
I don't know.
I just don't want call myself idiot when it happens.
I think it would be much better to put this in fs/aufs/aufs.h and make
each of fs/aufs/*.c include that first.
Yes, that is my another option I have
Thorsten Glaser:
What do you think of this (untested)?
well, it compiles (with warnings, see below). I=E2=80=99ll know if it links
and loads tomorrow, I guess (unless the other problems are still
there).
:::
This is the last version of my approach (documentations are omitted).
Would
Hello Ben,
Ben Hutchings:
AUFS_NAME is only defined in aufs_type.h but pr_fmt may be used in
headers included before aufs_type.h.
Thanx for bug reporting and a patch.
I don't think the current macro will be a problem, but I want you to
test this patch since I don't have m68k environment.
It
(While I don't know this mail is delivered expectedly, I am sending to
debian-live and debian-kernel ML too since Ben Hutchings requested me to
do so. Note that aufs-users ML is members only and your reply may be
rejected.)
Hello Ben,
Ben Hutchings:
If there are important bug fixes that
Ben Hutchings:
I was hoping you would be able to identify the most important fixes,
dealing with data loss and security bugs. This long list of changes
appears to include cleanup and new features, which would not be
No, such changes are removed.
You may be able to see what I have removed if
Ben Hutchings:
The code says:
BUILD_BUG_ON(sizeof(ino_t) !=3D sizeof(long));
return ALIGN(sizeof(struct au_vdir_de) + nlen, sizeof(ino_t));
but on alpha, sizeof(ino_t) =3D=3D 4 but sizeof(long) =3D=3D 8.
I decided to remove the BUILD_BUG_ON() line simply. If you want to
Hello Ben,
Ben Hutchings:
The code says:
BUILD_BUG_ON(sizeof(ino_t) !=3D sizeof(long));
return ALIGN(sizeof(struct au_vdir_de) + nlen, sizeof(ino_t));
but on alpha, sizeof(ino_t) =3D=3D 4 but sizeof(long) =3D=3D 8.
Is it really necessary that these types have the same
19 matches
Mail list logo
