All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Jessica Yu <jeyu@redhat.com>, Miroslav Benes <mbenes@suse.cz>,
	sjenning@redhat.com, vojtech@suse.com, pmladek@suse.cz,
	mpe@ellerman.id.au, live-patching@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: klp: remove superfluous errors in asm/livepatch.h
Date: Wed, 9 Mar 2016 10:11:23 -0600	[thread overview]
Message-ID: <20160309161123.GB21308@treble.redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1603091136430.3656@cbobk.fhfr.pm>

On Wed, Mar 09, 2016 at 11:39:05AM +0100, Jiri Kosina wrote:
> On Tue, 8 Mar 2016, Jessica Yu wrote:
> 
> > Hm, I should've caught this earlier, but the notifier cleanup patch
> > that removes the livepatch module notifier had kernel/module.c include
> > livepatch.h for the klp_module_{coming,going} function stubs in the
> > !CONFIG_LIVEPATCH case. See here: https://lkml.org/lkml/2016/2/8/1182
> > 
> > Looking back, I now don't think it makes sense for module.c to include
> > all those livepatch definitions in the first place, since all it
> > needed was the klp_module_{coming,going} declarations. I guess my
> > question is, since we've removed the #ifdef CONFIG_LIVEPATCH blocks
> > from livepatch.h, where might be a better place for the
> > klp_module_{coming,going} stubs? Perhaps they could go in module.h
> > instead?
> 
> Well, once there actually are alternate stubs to be included through the 
> header file (like in the proposed notifier removal), it indeed makes sense 
> to reintroduce the #ifdef. And once it's there, it probably doesn't make 
> too much sense to have it guard only portion of the file.

It's a minor issue but I think it would be cleaner if we only guard the
parts of the file which need to be guarded.

-- 
Josh

  reply	other threads:[~2016-03-09 16:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04  9:53 [PATCH] klp: remove superfluous errors in asm/livepatch.h Miroslav Benes
2016-03-04 21:45 ` Josh Poimboeuf
2016-03-06 21:13   ` Jiri Kosina
2016-03-07  4:10     ` Josh Poimboeuf
2016-03-08 21:28     ` Jessica Yu
2016-03-09 10:06       ` Petr Mladek
2016-03-09 10:39       ` Jiri Kosina
2016-03-09 16:11         ` Josh Poimboeuf [this message]
2016-03-15 11:37   ` [PATCH] " Miroslav Benes

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=20160309161123.GB21308@treble.redhat.com \
    --to=jpoimboe@redhat.com \
    --cc=jeyu@redhat.com \
    --cc=jikos@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mpe@ellerman.id.au \
    --cc=pmladek@suse.cz \
    --cc=sjenning@redhat.com \
    --cc=vojtech@suse.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.