public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [FOR REVIEW, PATCH 2/2] introduce "struct wait_opts" to simplify do_wait() pathes
Date: Thu, 7 May 2009 09:54:17 +0200	[thread overview]
Message-ID: <20090507075417.GA9836@elte.hu> (raw)
In-Reply-To: <20090507064120.GB15220@redhat.com>


* Oleg Nesterov <oleg@redhat.com> wrote:

> On 05/06, Ingo Molnar wrote:
> >
> > One small nit with the definition above: when using vertical spacing
> > (which really looks nice) we tend to put the asterix to the type
> > itself, not to the variable. I.e.:
> >
> > 	enum pid_type		wtype;
> > 	struct pid *		wpid;
> > 	int			wflags;
> >
> > ( This is done to separate the field name from the type - the
> >   pointer nature of the field is part of the type, not part of the
> >   name. )
> 
> Indeed, I like this more too. But checkpatch.pl disagrees!

That's probably a checkpatch bug mistaking * for multiplication - 
ignore checkpatch in that case and please report it to Andy 
Withcroft as well as well.

> > Regarding the patch itself: i guess we could do it as-is - but 
> > if you think there's regression risks, a safer approach would be 
> > to create 5-6 patches to build up all the structure parameters 
> > one by one.
> 
> Oh, I tried to do it this way first. But I got lost and decided to 
> make a single patch. Besides, if I make 6 patches I should try to 
> test each one...

One way to do it is to build-test them on a common config (say 
64-bit defconfig), and then boot test the final result. That makes 
it fully bisectable in 90% of the cases.

But ... it's really up to you. I'd be cautious out of box, as the 
quirk density in exit.c is still enormous and it's very easy to have 
some unintended side-effect.

	Ingo

  reply	other threads:[~2009-05-07  7:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-06  5:33 [FOR REVIEW, PATCH 2/2] introduce "struct wait_opts" to simplify do_wait() pathes Oleg Nesterov
2009-05-06  7:27 ` Ingo Molnar
2009-05-07  6:41   ` Oleg Nesterov
2009-05-07  7:54     ` Ingo Molnar [this message]
2009-05-09 16:15       ` Oleg Nesterov
2009-05-11 10:53         ` Andy Whitcroft
2009-05-11 12:43           ` Ingo Molnar
2009-05-06 20:09 ` Roland McGrath
2009-05-07  6:45   ` Oleg Nesterov
2009-05-07  7:20     ` Roland McGrath
2009-05-07  7:40       ` Oleg Nesterov
2009-05-07  7:49         ` Roland McGrath

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=20090507075417.GA9836@elte.hu \
    --to=mingo@elte.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=roland@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox