lkml.org 
[lkml]   [2007]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] include/linux/slab.h: new KFREE() macro.
Date
> --- Hua Zhong <hzhong@gmail.com> wrote:
>
> > > Any strong reason why not? x has some value that does not
> > > make sense and can create only problems.
> >
> > By the same logic, you should memset the buffer to zero
> before freeing it too.
> >
>
> How does this help?

It doesn't. I thought that was my point?

> > > And as I explained, it can result in longer code too. So, why
> > > keep this value around. Why not re-initialize it to NULL.
> >
> > Because initialization increases code size.
>
> Then why use kzalloc()? Let's remove _ALL_ the initialization
> code from the kernel.

You initialize before use, not after.

> Attached is some code from the kernel. Expanded KFREE() has
> been used atleast 1000 times in the
> kernel. By your logic, everyone is stupid in doing so.
> Something has been done atleast 1000 times
> in the kernel, that looks okay. But consolidating it at one
> place does not look okay. I am listing
> some of the 1000 places where KFREE() has been used. All this
> code have been written by atleast 50
> different people. From your logic they were doing "silly" things.

Maybe you should first each one of them and see why they do it.
And if there is no purpose than "better be safe than sorry",
maybe you can then submit a patch to fix it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-01-08 09:59    [from the cache]
©2003-2011 Jasper Spaans