* [PATCH] SLQB: Coding style cleanups
@ 2009-05-03 12:15 Pekka J Enberg
2009-05-05 8:25 ` Nick Piggin
0 siblings, 1 reply; 5+ messages in thread
From: Pekka J Enberg @ 2009-05-03 12:15 UTC (permalink / raw)
To: npiggin; +Cc: linux-kernel
From: Pekka Enberg <penberg@cs.helsinki.fi>
This patch cleans up SQLB to make the code checkpatch clean.
Cc: Nick Piggin <npiggin@suse.de>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
mm/slqb.c | 21 ++++++++++++---------
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/mm/slqb.c b/mm/slqb.c
index f538f2c..44a91c0 100644
--- a/mm/slqb.c
+++ b/mm/slqb.c
@@ -59,7 +59,7 @@ static inline void struct_slqb_page_wrong_size(void)
/*
* slqb_min_order: minimum allocation order for slabs
*/
-static int slqb_min_order = 0;
+static int slqb_min_order;
/*
* slqb_min_objects: minimum number of objects per slab. Increasing this
@@ -193,12 +193,12 @@ static inline void __free_slqb_pages(struct slqb_page *page, unsigned int order)
#ifdef CONFIG_SLQB_DEBUG
static inline int slab_debug(struct kmem_cache *s)
{
- return (s->flags &
+ return s->flags &
(SLAB_DEBUG_FREE |
SLAB_RED_ZONE |
SLAB_POISON |
SLAB_STORE_USER |
- SLAB_TRACE));
+ SLAB_TRACE);
}
static inline int slab_poison(struct kmem_cache *s)
{
@@ -945,7 +945,7 @@ static inline unsigned long kmem_cache_flags(unsigned long objsize,
return flags;
}
-static const int slqb_debug = 0;
+static const int slqb_debug;
#endif
/*
@@ -1954,8 +1954,11 @@ static struct kmem_cache_cpu *alloc_kmem_cache_cpu(struct kmem_cache *s,
int cpu)
{
struct kmem_cache_cpu *c;
+ int node;
+
+ node = cpu_to_node(cpu);
- c = kmem_cache_alloc_node(&kmem_cpu_cache, GFP_KERNEL, cpu_to_node(cpu));
+ c = kmem_cache_alloc_node(&kmem_cpu_cache, GFP_KERNEL, node);
if (!c)
return NULL;
@@ -2292,7 +2295,7 @@ error_lock:
up_write(&slqb_lock);
error:
if (flags & SLAB_PANIC)
- panic("kmem_cache_create(): failed to create slab `%s'\n", name);
+ panic("%s: failed to create slab `%s'\n", __func__, name);
return 0;
}
@@ -3006,7 +3009,7 @@ static int kmem_cache_create_ok(const char *name, size_t size,
if (!strcmp(tmp->name, name)) {
printk(KERN_ERR
- "kmem_cache_create(): duplicate cache %s\n", name);
+ "SLAB: duplicate cache %s\n", name);
dump_stack();
up_read(&slqb_lock);
@@ -3042,7 +3045,7 @@ struct kmem_cache *kmem_cache_create(const char *name, size_t size,
err:
if (flags & SLAB_PANIC)
- panic("kmem_cache_create(): failed to create slab `%s'\n", name);
+ panic("%s: failed to create slab `%s'\n", __func__, name);
return NULL;
}
@@ -3676,7 +3679,7 @@ static struct kset_uevent_ops slab_uevent_ops = {
static struct kset *slab_kset;
-static int sysfs_available __read_mostly = 0;
+static int sysfs_available __read_mostly;
static int sysfs_slab_add(struct kmem_cache *s)
{
--
1.5.6.3
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] SLQB: Coding style cleanups
2009-05-03 12:15 [PATCH] SLQB: Coding style cleanups Pekka J Enberg
@ 2009-05-05 8:25 ` Nick Piggin
2009-05-05 8:37 ` Pekka Enberg
0 siblings, 1 reply; 5+ messages in thread
From: Nick Piggin @ 2009-05-05 8:25 UTC (permalink / raw)
To: Pekka J Enberg; +Cc: linux-kernel
On Sun, May 03, 2009 at 03:15:10PM +0300, Pekka Enberg wrote:
> From: Pekka Enberg <penberg@cs.helsinki.fi>
>
> This patch cleans up SQLB to make the code checkpatch clean.
Thanks!
>
> Cc: Nick Piggin <npiggin@suse.de>
> Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
> ---
> mm/slqb.c | 21 ++++++++++++---------
> 1 files changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/mm/slqb.c b/mm/slqb.c
> index f538f2c..44a91c0 100644
> --- a/mm/slqb.c
> +++ b/mm/slqb.c
> @@ -59,7 +59,7 @@ static inline void struct_slqb_page_wrong_size(void)
> /*
> * slqb_min_order: minimum allocation order for slabs
> */
> -static int slqb_min_order = 0;
> +static int slqb_min_order;
I actually like explicit zero initializers. I think it has been
a long time since this actually saved any memory with gcc.
Yes yes, I know that anybody who can "read C" will read the
implicit zero initializer anyway... however I just think it is
a stupid thing for checkpatch to warn against.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] SLQB: Coding style cleanups
2009-05-05 8:25 ` Nick Piggin
@ 2009-05-05 8:37 ` Pekka Enberg
2009-05-05 9:17 ` Nick Piggin
0 siblings, 1 reply; 5+ messages in thread
From: Pekka Enberg @ 2009-05-05 8:37 UTC (permalink / raw)
To: Nick Piggin; +Cc: linux-kernel
Hi Nick,
On Tue, May 5, 2009 at 11:25 AM, Nick Piggin <npiggin@suse.de> wrote:
>> @@ -59,7 +59,7 @@ static inline void struct_slqb_page_wrong_size(void)
>> /*
>> * slqb_min_order: minimum allocation order for slabs
>> */
>> -static int slqb_min_order = 0;
>> +static int slqb_min_order;
>
> I actually like explicit zero initializers. I think it has been
> a long time since this actually saved any memory with gcc.
>
> Yes yes, I know that anybody who can "read C" will read the
> implicit zero initializer anyway... however I just think it is
> a stupid thing for checkpatch to warn against.
OK. I guess I can drop those hunks. But from coding style of point
view we don't really do explicit zero initializers in the core
kernel...
Pekka
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] SLQB: Coding style cleanups
2009-05-05 8:37 ` Pekka Enberg
@ 2009-05-05 9:17 ` Nick Piggin
2009-05-05 12:18 ` Andy Whitcroft
0 siblings, 1 reply; 5+ messages in thread
From: Nick Piggin @ 2009-05-05 9:17 UTC (permalink / raw)
To: Pekka Enberg; +Cc: linux-kernel, apw
On Tue, May 05, 2009 at 11:37:32AM +0300, Pekka Enberg wrote:
> Hi Nick,
>
> On Tue, May 5, 2009 at 11:25 AM, Nick Piggin <npiggin@suse.de> wrote:
> >> @@ -59,7 +59,7 @@ static inline void struct_slqb_page_wrong_size(void)
> >> /*
> >> * slqb_min_order: minimum allocation order for slabs
> >> */
> >> -static int slqb_min_order = 0;
> >> +static int slqb_min_order;
> >
> > I actually like explicit zero initializers. I think it has been
> > a long time since this actually saved any memory with gcc.
> >
> > Yes yes, I know that anybody who can "read C" will read the
> > implicit zero initializer anyway... however I just think it is
> > a stupid thing for checkpatch to warn against.
>
> OK. I guess I can drop those hunks. But from coding style of point
> view we don't really do explicit zero initializers in the core
> kernel...
Well... it's not a big deal, but I just don't think it is a big
enough deal to have checkpatch complain about it. Whatever you
like. If you have already committed that version, then don't
worry about changing it.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] SLQB: Coding style cleanups
2009-05-05 9:17 ` Nick Piggin
@ 2009-05-05 12:18 ` Andy Whitcroft
0 siblings, 0 replies; 5+ messages in thread
From: Andy Whitcroft @ 2009-05-05 12:18 UTC (permalink / raw)
To: Nick Piggin; +Cc: Pekka Enberg, linux-kernel
On Tue, May 05, 2009 at 11:17:50AM +0200, Nick Piggin wrote:
> On Tue, May 05, 2009 at 11:37:32AM +0300, Pekka Enberg wrote:
> > Hi Nick,
> >
> > On Tue, May 5, 2009 at 11:25 AM, Nick Piggin <npiggin@suse.de> wrote:
> > >> @@ -59,7 +59,7 @@ static inline void struct_slqb_page_wrong_size(void)
> > >> /*
> > >> * slqb_min_order: minimum allocation order for slabs
> > >> */
> > >> -static int slqb_min_order = 0;
> > >> +static int slqb_min_order;
> > >
> > > I actually like explicit zero initializers. I think it has been
> > > a long time since this actually saved any memory with gcc.
> > >
> > > Yes yes, I know that anybody who can "read C" will read the
> > > implicit zero initializer anyway... however I just think it is
> > > a stupid thing for checkpatch to warn against.
> >
> > OK. I guess I can drop those hunks. But from coding style of point
> > view we don't really do explicit zero initializers in the core
> > kernel...
>
> Well... it's not a big deal, but I just don't think it is a big
> enough deal to have checkpatch complain about it. Whatever you
> like. If you have already committed that version, then don't
> worry about changing it.
Yeah we did talk about it once before. At that time I did some
experiments and confirmed that there was no space to be saved. However
the discussion never came to a conclusion. For myself I am happy to
remove this check if it has outlived its usefulness.
-apw
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-05-05 12:18 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-03 12:15 [PATCH] SLQB: Coding style cleanups Pekka J Enberg
2009-05-05 8:25 ` Nick Piggin
2009-05-05 8:37 ` Pekka Enberg
2009-05-05 9:17 ` Nick Piggin
2009-05-05 12:18 ` Andy Whitcroft
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).