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
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 features, so it's not suitable
to export through "feature-".
One
27 matches
Mail list logo
