Re: linux-next: Tree for Oct 14 (bcache)

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]

On Mon, Oct 14, 2013 at 11:58:10AM -0700, Randy Dunlap wrote:
> On 10/14/13 07:48, Thierry Reding wrote:
> > Hi all,
> > 
> > I've uploaded today's linux-next tree to the master branch of the
> > repository below:
> > 
> >         git://gitorious.org/thierryreding/linux-next.git
> > 
> > A next-20131014 tag is also provided for convenience.
> > 
> > Gained a few conflicts, but nothing too exciting. x86 and ARM default
> > configurations build fine. There were some build failures unrelated to
> 
> Maybe you could build allmodconfig instead of a default config
> for more better coverage?  I am seeing lots of build problems.

Ideally I'd be able to run allmodconfig for each merge, but I have
neither the computing power nor the time to do that. I can add
allmodconfig to the set of configurations that I build after the final
merge, but I don't know how much good that is if I don't actually have
any time to fix them up.

Furthermore I'm beginning to think that perhaps we should create some
infrastructure around this that would make it easier to submit requests
for build coverage. Quite a few people seem to run autobuilders, so if
all those could be harnessed to build linux-next (perhaps even on a per
merge basis) that would give great coverage.

> > the merge, most of which I fixed and added as patches on top of the
> > final merge.
> 
> 
> on x86_64:
> 
> drivers/md/bcache/request.c: In function 'cached_dev_write':
> drivers/md/bcache/request.c:1076:8: error: 'struct btree_op' has no member named 'cache_bio'

It's quite possible that I messed that up during the merge. The bcache
conflicts weren't very trivial. This one in particular seems to be
caused by a commit that went into 3.12-rc5 and one in the block tree's
linux-next branch.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]