RE: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
>
> Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
> > It's getting hard to parse the thread at this point but, as I've
> > mentioned in a previo
On Tue, Mar 22, 2016 at 04:14:40PM +, Ian Jackson wrote:
> Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
> > It's getting hard to parse the thread at this point but, as I've
> > mentioned in a previous res
On Tue, Mar 22, 2016 at 04:11:35PM +, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
> > > I don't think this is a sterile academic conversation which would (if
> > > satisfactor
>>> On 22.03.16 at 16:27, wrote:
> On Tue, Mar 22, 2016 at 03:12:02PM +, Ian Jackson wrote:
>> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
>> > On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote
Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document
scsi/0x12/0x83 node"):
> It's getting hard to parse the thread at this point but, as I've
> mentioned in a previous response in the thread, Windows basically
> assumes disks are SCSI and it's u
Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
scsi/0x12/0x83 node"):
> > I don't think this is a sterile academic conversation which would (if
> > satisfactorily answered) have no real implications. Rather, if we
> > understood t
RE: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
>
> Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
> > AFAIK XenServer still very much makes use of it.
>
> Can you answer, for XenServer's use
On Tue, Mar 22, 2016 at 03:12:02PM +, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
> > On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote:
> > > Just think of it as a black box.
> >
> &
David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
scsi/0x12/0x83 node"):
> On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote:
> > Just think of it as a black box.
>
> This isn't sufficient.
>
> You are presenting a solution but have not proper
Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document
scsi/0x12/0x83 node"):
> AFAIK XenServer still very much makes use of it.
Can you answer, for XenServer's use case, some of the questions that
David and I have asked ?
Ian.
_
Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
>
> On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote:
> > On Tue, Mar 22, 2016 at 01:41:43PM +, David Vrabel wrote:
> >> On 22/03/16 12:55, Bob Liu wrote:
> >>>
> >>> On 03/17/2016 07:12
On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 22, 2016 at 01:41:43PM +, David Vrabel wrote:
>> On 22/03/16 12:55, Bob Liu wrote:
>>>
>>> On 03/17/2016 07:12 PM, Ian Jackson wrote:
>>>> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH]
On Tue, Mar 22, 2016 at 01:41:43PM +, David Vrabel wrote:
> On 22/03/16 12:55, Bob Liu wrote:
> >
> > On 03/17/2016 07:12 PM, Ian Jackson wrote:
> >> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
> >> scsi/0x12/0x83 node&quo
On 22/03/16 12:55, Bob Liu wrote:
>
> On 03/17/2016 07:12 PM, Ian Jackson wrote:
>> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
>> scsi/0x12/0x83 node"):
>>> On 16/03/16 13:59, Bob Liu wrote:
>>>> But we'd like t
On 03/17/2016 07:12 PM, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
>> On 16/03/16 13:59, Bob Liu wrote:
>>> But we'd like to get the VPD information(of underlying storage device) also
>
On 03/16/2016 10:32 PM, David Vrabel wrote:
> On 16/03/16 13:59, Bob Liu wrote:
>>
>> But we'd like to get the VPD information(of underlying storage device) also
>> in Linux blkfront, even blkfront is not a SCSI device.
>
> Why does blkback/blkfront need to involved here? This is just some
> xe
David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
scsi/0x12/0x83 node"):
> On 17/03/16 11:12, Ian Jackson wrote:
> > David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
> > scsi/0x12/0x83 node"):
> >> On 16/03/16 13:5
> -Original Message-
> From: Bob Liu [mailto:bob@oracle.com]
> Sent: 16 March 2016 13:59
> To: Ian Jackson
> Cc: xen-devel@lists.xen.org; Paul Durrant; konrad.w...@oracle.com;
> jgr...@suse.com; Roger Pau Monne; annie...@oracle.com
> Subject: Re: [RFC PATCH] blkif.h: document scsi/0x12/
On 03/16/2016 10:07 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Bob Liu [mailto:bob@oracle.com]
..snip..
>>>
>>
>> But we'd like to get the VPD information(of underlying storage device) also
>> in
>> Linux blkfront, even blkfront is not a SCSI device.
>>
>> That's because o
David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
scsi/0x12/0x83 node"):
> On 16/03/16 13:59, Bob Liu wrote:
> > But we'd like to get the VPD information(of underlying storage device) also
> > in Linux blkfront, even blkfront is not a SCSI device.
Bob Liu writes ("[RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> Sometimes, we need to query VPD page=0x83 data from underlying
> storage so that vendor supplied software can run inside the VM and
> believe it's talking to the vendor's own storage. But different
> vendors may have different
On 17/03/16 11:12, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
>> On 16/03/16 13:59, Bob Liu wrote:
>>> But we'd like to get the VPD information(of underlying storage device) also
>>&
On 03/16/2016 08:36 PM, Ian Jackson wrote:
> Bob Liu writes ("[RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
>> Sometimes, we need to query VPD page=0x83 data from underlying
>> storage so that vendor supplied software can run inside the VM and
>> believe it's talking to the vendor's own sto
On 16/03/16 13:59, Bob Liu wrote:
>
> But we'd like to get the VPD information(of underlying storage device) also
> in Linux blkfront, even blkfront is not a SCSI device.
Why does blkback/blkfront need to involved here? This is just some
xenstore keys that can be written by the toolstack and di
Bob Liu writes ("Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> That's because our underlying storage device has some vendor-specific
> features which can be recognized through informations in VPD pages.
> And Our applications in guest want to aware of these vendor-specific features.
On Wed, Mar 16, 2016 at 11:09:05AM +0800, Bob Liu wrote:
> Sometimes, we need to query VPD page=0x83 data from underlying storage so
> that vendor supplied software can run inside the VM and believe it's talking
> to
> the vendor's own storage.
> But different vendors may have different special fe
26 matches
Mail list logo
