From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm,arm64: Conditionalize bio_vec usage
Date: Mon, 11 Nov 2013 10:14:53 +0100 [thread overview]
Message-ID: <20131111091452.GE3884@ulmo.nvidia.com> (raw)
In-Reply-To: <CAOesGMjCeTeoF3M4UNY4zzAMyBFLddcwaXU91ur28hGca2uBHA@mail.gmail.com>
On Wed, Nov 06, 2013 at 07:40:43AM -0800, Olof Johansson wrote:
> On Wed, Nov 6, 2013 at 5:05 AM, Thierry Reding <thierry.reding@gmail.com> wrote:
> > Commit 3d1975b57097 (arm,arm64: do not always merge bio_vec if we are
> > running on Xen) unconditionally added code using the bio_vec typedefs
> > which causes build errors on configurations where CONFIG_BLOCK is
> > disabled.
> >
> > Add #ifdef CONFIG_BLOCK protection to fix this.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> I commented on the offending patch (which is a good way to make people
> aware of it instead of posting standalone patches like you did),
The standalone patch got Stefano's attention, so I don't see why you
think it was a bad idea.
I don't expect such patches to always be applied as is. If they aren't
proper fixes and someone comes up with a much better way (which they did
in this case), then I'm just as happy. Also it actually takes about the
same amount of time to write up a patch, compile-test it and send it out
than it takes to complain about the breakage by mail. I also find it
slightly more helpful than just telling somebody that their patch broke
something.
Perhaps this is a bad example because it's really a trivial issue, but
if it were anything slightly more complex, then sending a patch for it
may save some maintainer the additional work. I don't immediately see
what's wrong with that. Perhaps you'd care to elaborate.
> and Stefano posted patch that declares struct bio_vec; instead.
>
> Either way is ok with me, I'd generally prefer to avoid the ifdefs though.
I agree, that's much nicer than the #ifdef.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131111/1700a2d2/attachment.sig>
next prev parent reply other threads:[~2013-11-11 9:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 13:05 [PATCH] arm,arm64: Conditionalize bio_vec usage Thierry Reding
2013-11-06 15:29 ` Catalin Marinas
2013-11-06 16:21 ` Stefano Stabellini
2013-11-11 9:20 ` Thierry Reding
2013-11-06 15:40 ` Olof Johansson
2013-11-11 9:14 ` Thierry Reding [this message]
2013-11-06 16:19 ` Stefano Stabellini
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=20131111091452.GE3884@ulmo.nvidia.com \
--to=thierry.reding@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.