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

James Bottomley
2008-07-16T15:12:05Z

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