All of lore.kernel.org
 help / color / mirror / Atom feed
From: sfjro@users.sourceforge.net
To: Thorsten Glaser <tg@mirbsd.de>
Cc: aufs-users@lists.sourceforge.net,
	Debian kernel team <debian-kernel@lists.debian.org>,
	linux-m68k@vger.kernel.org
Subject: Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt
Date: Mon, 02 Jan 2012 11:58:13 +0900	[thread overview]
Message-ID: <5968.1325473093@jrobl> (raw)
In-Reply-To: <Pine.BSM.4.64L.1112311628570.14351@herc.mirbsd.org>


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, perhaps the Makefile should
> >define it, and pass it with -D?
>
> Indeed. I like Ben=E2=80=99s patch better. But if it must be a separate
> file, please move the pr_fmt definition out of the Makefile and
> into that file, too. Code doesn=E2=80=99t belong into a Makefile IMHO.

You guys don't see "-imacros linux/aufs_name.h" in Makefile?
Or do I totaly miunderstand -imacros?

----------------------------------------------------------------------
> Ben Hutchings dixit:
>
> >-ccflags-y +=3D -D'pr_fmt(fmt)=3DAUFS_NAME"\040%s:%d:%s[%d]:\040"fmt,__fun=
> c__,__LINE__,current->comm,current->pid'
> >+ccflags-y +=3D -D'pr_fmt(fmt)=3D"aufs\040%s:%d:%s[%d]:\040"fmt,__func__,_=
> _LINE__,current->comm,current->pid'
>
> Sadly, this doesn=E2=80=99t work either:
	:::
> /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/arch/m68k/inclu=
> de/asm/hardirq.h:23:2: error: dereferencing pointer to incomplete type
	:::
> The difference between a static inline function and a pr=C3=A6processor
> macro makes the difference. I know, now, why I never used the former
> myself =E2=98=BA I guess =E2=80=9Ccurrent=E2=80=9D is not defined there.

That must be an error around the "current" macro which I was afraid.

----------------------------------------------------------------------

> What do you think of this (untested)? I omitted the Documentation/**
> patch as that part it not present in the Debian Linux kernel.
	:::
+#define AUFS_NAME		"aufs"
+#define pr_fmt(fmt)		AUFS_NAME"\040%s:%d:%s[%d]:\040"fmt,__func__,__LINE__,current->comm,current->pid

Here are the comments from me.
- aufs_name.h is used both in kernel-space and user-space, so we need
  "#ifdef __KERNEL__"
- the macro may already be defined, so we need "#ifndef pr_fmt"
  now we should decide which we force (choose), the pr_fmt macro we
  define in aufs or the one previously defined somewhere else.
And I chose "defined aufs aufs".
These are also reasons to put it in Makefile.

----------------------------------------------------------------------

> 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).
>
> /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/a=
> ufs_name.h:27:0: warning: "pr_fmt" redefined [enabled by default]
> /tmp/buildd/linux-2.6-3.2~rc7/debian/build/source_m68k_none/include/linux/p=
> rintk.h:152:0: note: this is the location of the previous definition
>
> Version 2 of this patch (attached) fixes this by #undef pr_fmt
> before defining it. Please decide whether you want to fix it

Yes, undefining will be necessary if we move the macro difinition into
the header file. Or we may add a condition "#ifndef pr_fmt" when we
define the macro in the header. In other words,
- adding a condition means giving precedence to the difinition in
  somewhere else.
- undefining means forcing the definition in aufs.
But this "forcing" is not enough since the macro can be defined _before_
including the header. I know you put "-include linux/aufs_name.h" in
Makefile, but it is not enough either since the macro _may_ be defined
in sched.h or somewhere else which will be included before aufs_name.h.
Also I understand it is not a big problem. But I hope you would agree
that unconditionally or blindly defined macro is effective (or less
subject to bug) in a single module.

So I still think it is better to define it in Makefile.
If I remove refering the "current" macro in the definition, then the
life will be easier, but it is still useful and I want to keep
it. Additonally it is not a essential problem I think.
Finally I'd like to add sched.h between aufs_name and pr_fmt (see the
attached patch).
How do you think?


J. R. Okajima

--- a/fs/aufs/Makefile
+++ b/fs/aufs/Makefile
@@ -10,6 +10,7 @@ endif
 ccflags-y += -DDEBUG
 # sparse doesn't allow spaces
 ccflags-y += -imacros linux/aufs_name.h
+ccflags-y += -include linux/sched.h
 ccflags-y += -D'pr_fmt(fmt)=AUFS_NAME"\040%s:%d:%s[%d]:\040"fmt,__func__,__LINE__,current->comm,current->pid'
 
 obj-$(CONFIG_AUFS_FS) += aufs.o

  reply	other threads:[~2012-01-02  2:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-30 17:06 [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt Ben Hutchings
2011-12-31  4:46 ` sfjro
2011-12-31  8:01   ` Geert Uytterhoeven
2011-12-31 16:31     ` Thorsten Glaser
2012-01-02  2:58       ` sfjro [this message]
2012-01-02  3:40         ` Ben Hutchings
2012-01-02  4:01           ` sfjro
2012-01-02  2:04     ` sfjro
2011-12-31 22:18 ` Thorsten Glaser
2011-12-31 22:31   ` Thorsten Glaser
2012-01-01  1:15     ` Thorsten Glaser
2012-01-02  6:45       ` sfjro
2012-01-02 10:31         ` Thorsten Glaser
2012-01-02 13:15           ` sfjro
2012-01-02 13:30             ` Thorsten Glaser
2012-01-02 13:53               ` sfjro
2012-01-02 16:14                 ` Thorsten Glaser
2012-01-02 16:53                   ` sfjro
2012-01-02 17:36                     ` Thorsten Glaser
2012-01-03  5:21                       ` [PATCH 0/2] aufs: headers (Re: [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt) sfjro
2012-01-03  5:21                       ` [PATCH 1/2] aufs: headers 1/2, bugfix, where the pr_fmt macro definition sfjro
2012-01-03  5:21                       ` [PATCH 2/2] aufs: headers 2/2, simply refined sfjro
2011-12-31 22:55   ` [PATCH] aufs: Do not refer to AUFS_NAME in pr_fmt Thorsten Glaser
2012-01-01  8:47     ` Geert Uytterhoeven
2012-01-01 14:48       ` Thorsten Glaser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5968.1325473093@jrobl \
    --to=sfjro@users.sourceforge.net \
    --cc=aufs-users@lists.sourceforge.net \
    --cc=debian-kernel@lists.debian.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=tg@mirbsd.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.