From: Randy Dunlap <randy.dunlap@oracle.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: Tree for August 6 (block git tree)
Date: Tue, 10 Aug 2010 09:11:08 -0700 [thread overview]
Message-ID: <4C617A1C.9000602@oracle.com> (raw)
In-Reply-To: <4C617956.70003@kernel.dk>
On 08/10/10 09:07, Jens Axboe wrote:
> On 08/10/2010 11:59 AM, Randy Dunlap wrote:
>> On Tue, 10 Aug 2010 11:56:34 -0400 Jens Axboe wrote:
>>
>>> On 08/10/2010 11:54 AM, Randy Dunlap wrote:
>>>> On 08/10/10 08:51, Jens Axboe wrote:
>>>>> On 08/10/2010 11:37 AM, Randy Dunlap wrote:
>>>>>> On Fri, 06 Aug 2010 12:06:00 -0700 Randy Dunlap wrote:
>>>>>>
>>>>>>> On 08/06/10 12:04, Randy Dunlap wrote:
>>>>>>>> On Fri, 6 Aug 2010 13:27:58 +1000 Stephen Rothwell wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> As the merge window is open, please do not add 2.6.37 material to your
>>>>>>>>> linux-next included trees until after 2.6.36-rc1.
>>>>>>>>>
>>>>>>>>> Changes since 20100805:
>>>>>>>>>
>>>>>>>>> The block tree lost its build failure and a conflict.
>>>>>>>>
>>>>>>>>
>>>>>>>> Lots of source files now need <linux/blk_types.h>:
>>>>>>>>
>>>>>>>> mm/filemap.c:2164: error: 'REQ_WRITE' undeclared
>>>>>>>> fs/read_write.c:362: error: 'REQ_WRITE' undeclared
>>>>>>>> fs/splice.c:1108: error: 'REQ_WRITE' undeclared
>>>>>>>> fs/aio.c:1496: error: 'REQ_WRITE' undeclared
>>>>>>>> drivers/memstick/core/memstick.c:272: error: 'REQ_WRITE' undeclared
>>>>>>>> drivers/memstick/host/tifm_ms.c:218: error: 'REQ_WRITE' undeclared
>>>>>>>> drivers/memstick/host/jmb38x_ms.c:333: error: 'REQ_WRITE' undeclared
>>>>>>>> drivers/staging/spectra/ffsport.c:277: error: 'REQ_TYPE_LINUX_BLOCK' undeclared
>>>>>>>> fs/compat.c:1274: error: 'REQ_WRITE' undeclared
>>>>>>>
>>>>>>>
>>>>>>> Sorry, I see that this has already been fixed.
>>>>>>
>>>>>> s/fixed/addressed/ but not yet merged into linux-next.
>>>>>> Can we get that fixed, please?
>>>>>
>>>>> Which patch are you referencing?
>>>>
>>>> Hi Jens,
>>>>
>>>> Maybe I misread last week's email about linux/blk_types.h.
>>>> (It was about being exported, not about being #included.)
>>>>
>>>> There are still lots of these files that have the errors listed above.
>>>> Has there been a patch for those?
>>>
>>> What's the .config?
>>
>> I have a bunch of them that fail. Here are 2 of them,
>> one with CONFIG_BLOCK=y and one with CONFIG_BLOCK=n.
>>
>> I can give you more if you want them.
>
> Looks like the types are badly hidden behind CONFIG_BLOCK.
> So this should fix the CONFIG_BLOCK=n part at least. What
> was the compile error with CONFIG_BLOCK=y?
Ugh, it is a staging driver with lots of other problems.
(spectra) I wouldn't worry about it for now.
I'll test this patch. Thanks.
>
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index 1185237..5369177 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -108,6 +108,8 @@ struct bio {
> #define BIO_POOL_MASK (1UL << BIO_POOL_OFFSET)
> #define BIO_POOL_IDX(bio) ((bio)->bi_flags >> BIO_POOL_OFFSET)
>
> +#endif /* CONFIG_BLOCK */
> +
> /*
> * Request flags. For use in the cmd_flags field of struct request, and in
> * bi_rw of struct bio. Note that some flags are only valid in either one.
> @@ -189,5 +191,4 @@ enum rq_flag_bits {
> #define REQ_IO_STAT (1 << __REQ_IO_STAT)
> #define REQ_MIXED_MERGE (1 << __REQ_MIXED_MERGE)
>
> -#endif /* CONFIG_BLOCK */
> #endif /* __LINUX_BLK_TYPES_H */
>
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
next prev parent reply other threads:[~2010-08-10 16:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-06 3:27 linux-next: Tree for August 6 Stephen Rothwell
2010-08-06 18:53 ` linux-next: Tree for August 6 (kgdboc) Randy Dunlap
2010-08-06 18:53 ` Randy Dunlap
2010-08-06 20:00 ` Jason Wessel
2010-08-06 20:00 ` Jason Wessel
2010-08-06 21:03 ` rdunlap
2010-08-06 19:04 ` linux-next: Tree for August 6 (block git tree) Randy Dunlap
2010-08-06 19:06 ` Randy Dunlap
2010-08-10 15:37 ` Randy Dunlap
2010-08-10 15:51 ` Jens Axboe
2010-08-10 15:54 ` Randy Dunlap
2010-08-10 15:56 ` Jens Axboe
2010-08-10 15:59 ` Randy Dunlap
2010-08-10 16:07 ` Jens Axboe
2010-08-10 16:11 ` Randy Dunlap [this message]
2010-08-10 16:14 ` Jens Axboe
2010-08-10 16:34 ` Randy Dunlap
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=4C617A1C.9000602@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/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.