Re: [build fix] Re: [GIT PATCH] SCSI part 1

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Wed, 2008-07-16 at 16:45 +0200, Ingo Molnar wrote:
> * James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > On Wed, 2008-07-16 at 16:18 +0200, Ingo Molnar wrote:
> > > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > > 
> > > > On Wed, 2008-07-16 at 15:15 +0200, Ingo Molnar wrote:
> > > > > * Ingo Molnar <mingo@elte.hu> wrote:
> > > > > 
> > > > > > > scsi_cmnd.h depends on symbols defined in blkdev.h. The fix is to 
> > > > > > > include blkdev.h as well.
> > > > > > 
> > > > > > that wont work - a better replacement fix is the one below. The 
> > > > > > problem is that scsi.h is included even on !CONFIG_BLOCK and then the 
> > > > > > BLK_MAX_CDB symbol is meaningless.
> > > > > 
> > > > > -v3 .. the new methods need to be under #ifdef CONFIG_BLOCK as well. 
> > > > > Note my patch is just a quick RFC, this can probably be done 
> > > > > cleaner.
> > > > 
> > > > Erm, Ingo, if you'd just follow linux-next instead of your own tree, 
> > > > you'd see there's already a fix for this.
> > > 
> > > Erm, no. In the merge window i follow upstream -git, not "my tree", and 
> > > i searched lkml for the build failure signature and it had nothing 
> > > there. Then i looked at the commit and it said that it was created just 
> > > 1 day before the merge window started:
> > > 
> > >  commit feac6a07c4a3578bffd6769bb4927e8a7e1f3ffe
> > >  Author:     Martin Petermann <martin@linux.vnet.ibm.com>
> > >  AuthorDate: Wed Jul 2 10:56:35 2008 +0200
> > >  Commit:     James Bottomley <James.Bottomley@HansenPartnership.com>
> > >  CommitDate: Sat Jul 12 08:22:34 2008 -0500
> > >                  ^^^^^^
> > > 
> > > So i didnt even think of it having hit linux-next so i didnt look into 
> > > the linux-next archives. lkml should have been Cc:-ed in this case, 
> > 
> > It was, that would be this email:
> > 
> > http://marc.info/?l=linux-kernel&m=121555252007662
> 
> right - i missed it because i limited my search based on the Jul 12 
> CommitDate. Why is the CommitDate in your commit _after_ the creation of 
> a fix to it? I have found the patch in linux-next as well now, but under 
> a different sha1 that was generated on July 7th.

Because my tree got rebased; some of the patches needed to be moved to
immediate fixes.

James