From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [target:for-next 20/20] drivers/scsi/virtio_scsi.c:531:48: error: dereferencing pointer to incomplete type Date: Wed, 28 May 2014 13:25:40 +0200 Message-ID: <5385C7B4.7080603@redhat.com> References: <537d6b74.lQGMmmapPq/MP5Nx%fengguang.wu@intel.com> <1400791590.26558.6.camel@haakon3.risingtidesystems.com> <537F12C1.4080407@redhat.com> <1400867110.30565.6.camel@haakon3.risingtidesystems.com> <1401229304.12413.24.camel@haakon3.risingtidesystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41829 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751778AbaE1LZs (ORCPT ); Wed, 28 May 2014 07:25:48 -0400 In-Reply-To: <1401229304.12413.24.camel@haakon3.risingtidesystems.com> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: "Nicholas A. Bellinger" , "Martin K. Petersen" Cc: kbuild test robot , kbuild-all@01.org, linux-scsi Il 28/05/2014 00:21, Nicholas A. Bellinger ha scritto: > On Mon, 2014-05-26 at 13:30 -0400, Martin K. Petersen wrote: >>>>>>> "Nic" == Nicholas A Bellinger writes: >> >>>> What about #ifdef'ing VIRTIO_SCSI_F_T10_PI support out if >>>> !CONFIG_BLK_DEV_INTEGRITY? >> >> Nic> I figured it was slightly cleaner to enable BLK_DEV_INTEGRITY by >> Nic> default when referencing struct blk_integrity (following what >> Nic> IBLOCK does), than adding the equivalent #ifdef's.. >> >> Nic> MKP, do you have a preference on this..? >> >> Well, I guess how important the virtio stuff is in the embedded space? >> >> In the block layer we have all these wrappers that allow things to Do >> The Right Thing when the BLK_DEV_INTEGRITY is disabled. I'm not entirely >> sure it worth the hassle to do the same for target and virtio. The >> memory savings aren't that big to begin with. >> >> And besides, the bip pointer field in struct bio is about to become >> generic with my impending copy offload patches anyway, >> > > In that case, I'll leave as is unless Paolo has an objection. No, that's fine. Paolo