All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Jianyu Zhan <nasa4836@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] blk-cgroup: explicitly init the early_init field
Date: Tue, 22 Apr 2014 15:15:57 -0600	[thread overview]
Message-ID: <5356DC0D.7090305@kernel.dk> (raw)
In-Reply-To: <CAHz2CGXcTZZHYK1WbOcF3S-O74dxE+yN9z527KhgOOEcfD_-DQ@mail.gmail.com>

On 04/22/2014 08:18 AM, Jianyu Zhan wrote:
> On Tue, Apr 22, 2014 at 10:16 PM, Jens Axboe <axboe@kernel.dk> wrote:
>> The rest of the members will be zero-filled by default, so your patch should
>> not change anything.
> 
> Hi, Jens
> 
> I'm sorry I should have made this more clear.
> 
> Sure, for this global variable struct, if not initailized, its all
> fields will be initialized
> to 0 or null(depending on its type).  The point here is no to deprive
> the rights of compiler/linker of doing this initialization, it is mainly for
> documentation reason. Actually this field's value would affect how ->css_alloc
> should implemented.
> 
> Concretely, if early_init is nonzero, then ->css_alloc *must not* call kzalloc,
> because in cgroup implementation, ->css_alloc will be called earlier before
> mm_init().
> 
> I don't think that the value of one field(early_init) has a so subtle
> restrition on the another field(css_alloc) is a good thing, but since
> it is there, docment it should be needed.

Then just add the comment instead. The fact the members following the
last " = something," are zeroed is a common theme in the kernel, if you
just add a patch that blindly (and unnecessarily) zeroes one other
member, somebody else will likely find that odd and remove it again.

To be honest, I don't see much of a need to do anything here, really.

-- 
Jens Axboe


      reply	other threads:[~2014-04-22 21:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-22  5:26 [PATCH] blk-cgroup: explicitly init the early_init field Jianyu Zhan
2014-04-22 14:16 ` Jens Axboe
2014-04-22 14:18   ` Jianyu Zhan
2014-04-22 21:15     ` Jens Axboe [this message]

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=5356DC0D.7090305@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nasa4836@gmail.com \
    /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.