From: Joe Perches <joe@perches.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Greg KH <gregkh@linuxfoundation.org>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org,
rcu@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Where is the declaration of buffer used in kernel_param_ops .get functions?
Date: Sat, 03 Oct 2020 19:11:30 -0700 [thread overview]
Message-ID: <9541b95e9b36e606d62174aa46ec8265f36652d6.camel@perches.com> (raw)
In-Reply-To: <20201004013626.GE20115@casper.infradead.org>
On Sun, 2020-10-04 at 02:36 +0100, Matthew Wilcox wrote:
> On Sat, Oct 03, 2020 at 06:19:18PM -0700, Joe Perches wrote:
> > These patches came up because I was looking for
> > the location of the declaration of the buffer used
> > in kernel/params.c struct kernel_param_ops .get
> > functions.
> >
> > I didn't find it.
> >
> > I want to see if it's appropriate to convert the
> > sprintf family of functions used in these .get
> > functions to sysfs_emit.
> >
> > Patches submitted here:
> > https://lore.kernel.org/lkml/5d606519698ce4c8f1203a2b35797d8254c6050a.1600285923.git.joe@perches.com/T/
> >
> > Anyone know if it's appropriate to change the
> > sprintf-like uses in these functions to sysfs_emit
> > and/or sysfs_emit_at?
>
> There's a lot of preprocessor magic to wade through.
>
> I'm pretty sure this comes through include/linux/moduleparam.h
> and kernel/module.c.
Dunno, looked there, still can't find it.
btw:
The __module_param_call macro looks very dodgy
as it uses both __used and __attribute__((unused))
and likely one of them should be removed (unused?)
It looks like the comes from varying definitions of
__attribute_used__ eventually converted to __used
for old gcc versions 2, 3, and 4.
1da177e4c3f4:include/linux/compiler-gcc2.h:#define __attribute_used__ __attribute__((__unused__))
1da177e4c3f4:include/linux/compiler-gcc3.h:# define __attribute_used__ __attribute__((__used__))
1da177e4c3f4:include/linux/compiler-gcc3.h:# define __attribute_used__ __attribute__((__unused__))
1da177e4c3f4:include/linux/compiler-gcc4.h:#define __attribute_used__ __attribute__((__used__))
Maybe:
---
include/linux/moduleparam.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 47879fc7f75e..fc820b27fb00 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -288,10 +288,10 @@ struct kparam_array
/* Default value instead of permissions? */ \
static const char __param_str_##name[] = prefix #name; \
static struct kernel_param __moduleparam_const __param_##name \
- __used \
- __attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void *)))) \
- = { __param_str_##name, THIS_MODULE, ops, \
- VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg } }
+ __used __section("__param") __aligned(sizeof(void *)) = { \
+ __param_str_##name, THIS_MODULE, ops, \
+ VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg } \
+ }
/* Obsolete - use module_param_cb() */
#define module_param_call(name, _set, _get, arg, perm) \
WARNING: multiple messages have this Message-ID
From: Joe Perches <joe@perches.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: kvm@vger.kernel.org, Greg KH <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org,
rcu@vger.kernel.org, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: Where is the declaration of buffer used in kernel_param_ops .get functions?
Date: Sat, 03 Oct 2020 19:11:30 -0700 [thread overview]
Message-ID: <9541b95e9b36e606d62174aa46ec8265f36652d6.camel@perches.com> (raw)
In-Reply-To: <20201004013626.GE20115@casper.infradead.org>
On Sun, 2020-10-04 at 02:36 +0100, Matthew Wilcox wrote:
> On Sat, Oct 03, 2020 at 06:19:18PM -0700, Joe Perches wrote:
> > These patches came up because I was looking for
> > the location of the declaration of the buffer used
> > in kernel/params.c struct kernel_param_ops .get
> > functions.
> >
> > I didn't find it.
> >
> > I want to see if it's appropriate to convert the
> > sprintf family of functions used in these .get
> > functions to sysfs_emit.
> >
> > Patches submitted here:
> > https://lore.kernel.org/lkml/5d606519698ce4c8f1203a2b35797d8254c6050a.1600285923.git.joe@perches.com/T/
> >
> > Anyone know if it's appropriate to change the
> > sprintf-like uses in these functions to sysfs_emit
> > and/or sysfs_emit_at?
>
> There's a lot of preprocessor magic to wade through.
>
> I'm pretty sure this comes through include/linux/moduleparam.h
> and kernel/module.c.
Dunno, looked there, still can't find it.
btw:
The __module_param_call macro looks very dodgy
as it uses both __used and __attribute__((unused))
and likely one of them should be removed (unused?)
It looks like the comes from varying definitions of
__attribute_used__ eventually converted to __used
for old gcc versions 2, 3, and 4.
1da177e4c3f4:include/linux/compiler-gcc2.h:#define __attribute_used__ __attribute__((__unused__))
1da177e4c3f4:include/linux/compiler-gcc3.h:# define __attribute_used__ __attribute__((__used__))
1da177e4c3f4:include/linux/compiler-gcc3.h:# define __attribute_used__ __attribute__((__unused__))
1da177e4c3f4:include/linux/compiler-gcc4.h:#define __attribute_used__ __attribute__((__used__))
Maybe:
---
include/linux/moduleparam.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index 47879fc7f75e..fc820b27fb00 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -288,10 +288,10 @@ struct kparam_array
/* Default value instead of permissions? */ \
static const char __param_str_##name[] = prefix #name; \
static struct kernel_param __moduleparam_const __param_##name \
- __used \
- __attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void *)))) \
- = { __param_str_##name, THIS_MODULE, ops, \
- VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg } }
+ __used __section("__param") __aligned(sizeof(void *)) = { \
+ __param_str_##name, THIS_MODULE, ops, \
+ VERIFY_OCTAL_PERMISSIONS(perm), level, flags, { arg } \
+ }
/* Obsolete - use module_param_cb() */
#define module_param_call(name, _set, _get, arg, perm) \
next prev parent reply other threads:[~2020-10-04 2:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-04 0:18 [PATCH 0/4] treewide: Make definitions of struct kernel_param_ops const Joe Perches
2020-10-04 0:18 ` [PATCH 1/4] KVM: PPC: Book3S HV: Make struct kernel_param_ops definition const Joe Perches
2020-10-04 0:18 ` Joe Perches
2020-10-19 16:01 ` Paolo Bonzini
2020-10-19 16:01 ` Paolo Bonzini
2020-10-04 0:18 ` [PATCH 2/4] kvm x86/mmu: Make struct kernel_param_ops definitions const Joe Perches
2020-10-05 17:14 ` Ben Gardon
2020-10-19 15:50 ` Paolo Bonzini
2020-10-04 0:18 ` [PATCH 3/4] rcu/tree: " Joe Perches
2020-10-04 15:54 ` Paul E. McKenney
2020-10-04 0:18 ` [PATCH 4/4] mm/zswap: " Joe Perches
2020-10-04 1:19 ` Where is the declaration of buffer used in kernel_param_ops .get functions? Joe Perches
2020-10-04 1:19 ` Joe Perches
2020-10-04 1:19 ` Joe Perches
2020-10-04 1:36 ` Matthew Wilcox
2020-10-04 1:36 ` Matthew Wilcox
2020-10-04 2:11 ` Joe Perches [this message]
2020-10-04 2:11 ` Joe Perches
2020-10-04 2:11 ` Joe Perches
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=9541b95e9b36e606d62174aa46ec8265f36652d6.camel@perches.com \
--to=joe@perches.com \
--cc=gregkh@linuxfoundation.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=rcu@vger.kernel.org \
--cc=willy@infradead.org \
/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.