[PATCH 0/2] aufs: headers (Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt)

From: J. R. Okajima 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 of my control. Anyway

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

sf...@users.sourceforge.net dixit: >Hold it please. OK. >I am going to make more changes. So it is better to git-pull and test >the aufs GIT repository. Please send patches that _should_ apply against what’s in Debian. I don’t have time to play the merge game at the moment. >> I have the same

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

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 t

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

sf...@users.sourceforge.net dixit: >- AUFS_NAME is necessary for both of kernel-space and user-space. >- from userspace, users include aufs_type.h. to keep the consistency, > aufs_type.h should include aufs_name.h. >- for kernelspace, to put aufs_name.h _before_ all other headers. Hrm, okay. I’l

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

Thorsten Glaser: > Then, why include it in the Makefile at all? > (Or, why include aufs_name.h from aufs_type.h?) - AUFS_NAME is necessary for both of kernel-space and user-space. - from userspace, users include aufs_type.h. to keep the consistency, aufs_type.h should include aufs_name.h. - for

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

sf...@users.sourceforge.net dixit: >> You include aufs_name.h twice now, once in the Makefile, >> once in the header. Shouldn=E2=80=99t one be enough? > >No, because aufs_type.h is exported to userspace. Then, why include it in the Makefile at all? (Or, why include aufs_name.h from aufs_type.h?)

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

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 t

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

sf...@users.sourceforge.net dixit: >This is the last version of my approach (documentations are omitted). This doesn’t really differ from what I sent last, does it? >Would you try on your m68k when you have time? You _are_ aware that a kernel compile takes over a day, right? Why don’t you use t

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

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).

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

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 conside

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

On Mon, 2012-01-02 at 11:58 +0900, sf...@users.sourceforge.net wrote: > 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 embe

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

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

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

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 debian-kernel-r

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

Geert Uytterhoeven dixit: >Sorry, static inline functions are preferred over macros, unless there's Can I have reasons? (Also out of curiosity.) >a really good reason. Out-of-tree kernel code doing stupid things doesn't I see it like this: EVERY file that, directly or indirectly, includes hard

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

Hi Thorsten, On Sat, Dec 31, 2011 at 23:55, Thorsten Glaser wrote: > Dixi quod… > >>This one does work: >>http://lists.debian.org/debian-kernel/2011/12/msg00474.html > > Geert, would you please apply the attached patch, independent of > whether we are able to find a solution in aufs, as it avoids

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

Dixi quod… >What do you think of this (untested)? well, it compiles (with warnings, see below). I’ll know if it links and loads tomorrow, I guess (unless the other problems are still there). /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/aufs_name.h:27:0: warning: "pr

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

Dixi quod… >This one does work: >http://lists.debian.org/debian-kernel/2011/12/msg00474.html Geert, would you please apply the attached patch, independent of whether we are able to find a solution in aufs, as it avoids an entire problem class? Groeten uit Duitsland, //mirabilos -- [...] if mayb

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

Dixi quod… >go on. I can try a patch based on yours, but probably the best fix What do you think of this (untested)? I omitted the Documentation/** patch as that part it not present in the Debian Linux kernel. Please do not commit this anywhere until I say I have tested it. bye, //mirabilos --

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

Ben Hutchings dixit: >-ccflags-y += >-D'pr_fmt(fmt)=AUFS_NAME"\040%s:%d:%s[%d]:\040"fmt,__func__,__LINE__,current->comm,current->pid' >+ccflags-y += >-D'pr_fmt(fmt)="aufs\040%s:%d:%s[%d]:\040"fmt,__func__,__LINE__,current->comm,current->pid' Sadly, this doesn’t work either: CC [M] fs/aufs/m

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

sf...@users.sourceforge.net dixit: >test this patch since I don't have m68k environment. I can do that, but not too many patches at a time, since it takes easily a whole day to compile it. (Also, my own hacking time is limited atm.) >It introduces a new separated file include/linux/aufs_name.h.

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

On Sat, Dec 31, 2011 at 05:46, wrote: > +/* fs/aufs/Makefile refers this macro */ > +#define AUFS_NAME              "aufs" If the Makefile refers to the macro, perhaps the Makefile should define it, and pass it with -D? Gr{oetje,eeting}s,                         Geert -- Geert Uytterhoeven --

Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

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.

[PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt

AUFS_NAME is only defined in aufs_type.h but pr_fmt may be used in headers included before aufs_type.h. Signed-off-by: Ben Hutchings --- This should fix the build failure reported in . An alternative change was proposed in