From: Ingo Molnar <mingo@elte.hu>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [build fix] Re: [GIT PATCH] SCSI part 1
Date: Wed, 16 Jul 2008 16:45:01 +0200 [thread overview]
Message-ID: <20080716144501.GA4369@elte.hu> (raw)
In-Reply-To: <1216218498.3358.3.camel@localhost.localdomain>
* 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.
> Perhaps now you might see how even you can miss important stuff on
> such a high volume, low signal to noise ratio list ...
at least for me it's much easier to lose information if it's spread out
to hundreds of low volume lists. (have you ever tried to remain
subscribed on hundreds of lists at once? I have and it's not trivial at
all and the resulting loss of information and mails is frequent.)
Anyway, YMMV.
> > that's where people look for in case of upstream breakages. You
> > would have saved me some effort via that - please try to do it in
> > the future, it's very helpful to testers.
>
> Not if they miss the email, as you apparently did.
>
> > btw., about the technical aspects of the solution, i'm not sure i like
> > these big #ifdef blocks:
> >
> > > --- linux-next-20080708.orig/fs/compat_ioctl.c
> > > +++ linux-next-20080708/fs/compat_ioctl.c
> > > @@ -68,9 +68,11 @@
> > > #include <linux/capi.h>
> > > #include <linux/gigaset_dev.h>
> > >
> > > +#ifdef CONFIG_BLOCK
> > > #include <scsi/scsi.h>
> > > #include <scsi/scsi_ioctl.h>
> > > #include <scsi/sg.h>
> > > +#endif
> > >
> > > #include <asm/uaccess.h>
> > > #include <linux/ethtool.h>
> > > @@ -1965,6 +1967,7 @@ COMPATIBLE_IOCTL(GIO_UNISCRNMAP)
> > > COMPATIBLE_IOCTL(PIO_UNISCRNMAP)
> > > COMPATIBLE_IOCTL(PIO_FONTRESET)
> > > COMPATIBLE_IOCTL(PIO_UNIMAPCLR)
> > > +#ifdef CONFIG_BLOCK
> > > /* Big S */
> > > COMPATIBLE_IOCTL(SCSI_IOCTL_GET_IDLUN)
> > > COMPATIBLE_IOCTL(SCSI_IOCTL_DOORLOCK)
> > > @@ -1974,6 +1977,7 @@ COMPATIBLE_IOCTL(SCSI_IOCTL_GET_BUS_NUMB
> > > COMPATIBLE_IOCTL(SCSI_IOCTL_SEND_COMMAND)
> > > COMPATIBLE_IOCTL(SCSI_IOCTL_PROBE_HOST)
> > > COMPATIBLE_IOCTL(SCSI_IOCTL_GET_PCI)
> > > +#endif
> > > /* Big T */
> > > COMPATIBLE_IOCTL(TUNSETNOCSUM)
> > > COMPATIBLE_IOCTL(TUNSETDEBUG)
> > > @@ -2044,6 +2048,7 @@ COMPATIBLE_IOCTL(SIOCGIFVLAN)
> > > COMPATIBLE_IOCTL(SIOCSIFVLAN)
> > > COMPATIBLE_IOCTL(SIOCBRADDBR)
> > > COMPATIBLE_IOCTL(SIOCBRDELBR)
> > > +#ifdef CONFIG_BLOCK
> > > /* SG stuff */
> > > COMPATIBLE_IOCTL(SG_SET_TIMEOUT)
> > > COMPATIBLE_IOCTL(SG_GET_TIMEOUT)
> > > @@ -2068,6 +2073,7 @@ COMPATIBLE_IOCTL(SG_SCSI_RESET)
> > > COMPATIBLE_IOCTL(SG_GET_REQUEST_TABLE)
> > > COMPATIBLE_IOCTL(SG_SET_KEEP_ORPHAN)
> > > COMPATIBLE_IOCTL(SG_GET_KEEP_ORPHAN)
> > > +#endif
> > > /* PPP stuff */
> > > COMPATIBLE_IOCTL(PPPIOCGFLAGS)
> > > COMPATIBLE_IOCTL(PPPIOCSFLAGS)
> >
> > the clean solution we use everywhere else is to push such #ifdefs into
> > the headers, to make them generally includable. For example you can
> > include lockdep.h even if you dont have lockdep enabled, you can include
> > smp.h even on UP-only files, etc. etc.
>
> The problem being that compat stuff only needs to exist for block
> ioctls if block actually exists. If we're going to have a single
> giant file for all compat ioctls, then I think we have to fix it the
> way randy has done. If you want to separate it into say
> compat_block.h and simply
> #include that into compat.h then we can fix it more cleanly.
well i guess the primary question would be scsi.h: it used to be a
general header file, now it isnt. The ioctl definitions are OK under an
#ifdef i guess. Anyway, i've got no strong opinion, this was just an
observation.
Ingo
next prev parent reply other threads:[~2008-07-16 14:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-15 16:15 [GIT PATCH] SCSI part 1 James Bottomley
2008-07-16 10:16 ` [build fix] " Ingo Molnar
2008-07-16 10:33 ` Ingo Molnar
2008-07-16 13:15 ` Ingo Molnar
2008-07-16 13:28 ` Matthew Wilcox
2008-07-16 13:52 ` James Bottomley
2008-07-16 14:18 ` Ingo Molnar
2008-07-16 14:28 ` James Bottomley
2008-07-16 14:45 ` Ingo Molnar [this message]
2008-07-16 15:11 ` James Bottomley
2008-07-16 14:41 ` Matthew Wilcox
2008-07-16 14:46 ` Ingo Molnar
2008-07-16 14:57 ` Matthew Wilcox
2008-07-16 14:59 ` Ingo Molnar
2008-07-16 14:54 ` Ingo Molnar
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=20080716144501.GA4369@elte.hu \
--to=mingo@elte.hu \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox