Re: Re: Help please: bug#625 SCSI disk conflicts with blkfront---best approach for fix?

[Anthony Liguori <aliguori@us.ibm.com>]

On Tue, 20 Jun 2006 16:11:43 +0100, Keir Fraser wrote:

> 
> On 20 Jun 2006, at 15:59, Anthony Liguori wrote:
> 
>> The best fix is to stop hijacking major numbers that we don't own.
>>
>> This has been discussed on LKML and we've been told not to do this.  
>> The
>> longer we allow this the harder it will be for users when they 
>> eventually
>> have to switch over to xdX.
> 
> The bestest fix would be to hook into the SCSI subsystem as a SCSI 
> low-level driver, and (possibly, if necessary) extend our block 
> protocol to cope as necessary. :-)

I'm not sure that qualifies as bestest as blkfront isn't a SCSI device.  I
thought the kernel was moving away from pretending that things are SCSI
devices when they really aren't.

If we're going to emulate a SCSI device anyway for FV domains we could
just hijack that device's driver and make it hybrid (so that we could do
anything that we needed to do such that performance was as good as PV).

We could then just get rid of XenBus and use an emulated PCI bus to expose
devices.  :-)

Regards,

Anthony Liguori

> We can keep the existing blkfront 
> hooks into the block layer for IDE (where I expect it's harder to 
> create a new plug-n-play low-level driver) and for XdX.
> 
>   -- Keir