Xen devel - Jun 2006 - Help please: bug#625 SCSI disk conflicts with blkfront---best approach for fix?

I think bugzilla 625 is caused by compiling the scsi disk driver into
the domU kernel.  xen_blk can''t then get the SCSI major number 8.  This
is a usability issue because people create broken domU kernels and then
raise bugs.  What''s the best fix?  Changing the Kconfig files to
prohibit built in scsi disk when blkfront is enabled?  Is there a better
option?

Thanks,
Harry.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.

Regards,

Anthony Liguori

On Tue, 20 Jun 2006 12:21:17 +0100, Harry Butterworth wrote:
> I think bugzilla 625 is caused by compiling the scsi disk driver into
> the domU kernel.  xen_blk can''t then get the SCSI major number 8. 
This
> is a usability issue because people create broken domU kernels and then
> raise bugs.  What''s the best fix?  Changing the Kconfig files to
> prohibit built in scsi disk when blkfront is enabled?  Is there a better
> option?
> 
> Thanks,
> Harry.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

AL> The longer we allow this the harder it will be for users when they
AL> eventually have to switch over to xdX.

I very much agree.  What is the plan for switching over to xd devices
only?

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 2006-06-20 at 08:05 -0700, Dan Smith wrote:
> AL> The longer we allow this the harder it will be for users when they
> AL> eventually have to switch over to xdX.
> 
> I very much agree.  What is the plan for switching over to xd devices
> only?
It''s actually "xvdX".
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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. :-) 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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 20 Jun 2006, at 16:05, Dan Smith wrote:
> AL> The longer we allow this the harder it will be for users when they
> AL> eventually have to switch over to xdX.
>
> I very much agree.  What is the plan for switching over to xd devices
> only?
There isn''t one. We could add a compile option to make blkfront only 
understand xvdX. Then vendors can compile with that if they want.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 2006-06-20 at 16:13 +0100, Keir Fraser wrote:
> On 20 Jun 2006, at 16:05, Dan Smith wrote:
> 
> > AL> The longer we allow this the harder it will be for users when
they
> > AL> eventually have to switch over to xdX.
> >
> > I very much agree.  What is the plan for switching over to xd devices
> > only?
> 
> There isn''t one. We could add a compile option to make blkfront
only
> understand xvdX. Then vendors can compile with that if they want.
Currently Redhat (Fedora 5) Xen can understand xvdX . But Suse (OpenSuse
10.1) Xen cannot. Haven''t looked into it but this is just the case at
the moment.
> 
>   -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

KF> The bestest fix would be to hook into the SCSI subsystem as a SCSI
KF> low-level driver, and (possibly, if necessary) extend our block
KF> protocol to cope as necessary. :-)

That sounds cool, but I wonder about whether or not it''s necessary.
Presumably for an existing legacy distro (like FC4), all that is
needed for xvd support are some udev rules, is that right?  In that
case, why not just standardize on xvd for new distros and install some
udev rules for legacy distros?

Is there another benefit to having a low-level SCSI driver that I''m
missing?~

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 20 Jun 2006, at 16:24, Dan Smith wrote:
> KF> The bestest fix would be to hook into the SCSI subsystem as a SCSI
> KF> low-level driver, and (possibly, if necessary) extend our block
> KF> protocol to cope as necessary. :-)
>
> That sounds cool, but I wonder about whether or not it''s
necessary.
> Presumably for an existing legacy distro (like FC4), all that is
> needed for xvd support are some udev rules, is that right?  In that
> case, why not just standardize on xvd for new distros and install some
> udev rules for legacy distros?
>
> Is there another benefit to having a low-level SCSI driver that
I''m
> missing?
It could give us a framework for handling things like removable media 
better. Another, more bespoke, strategy is to develop that side of 
things further using xenbus as the signalling mechanism.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Dan Smith wrote:
> Is there another benefit to having a low-level SCSI driver that
I''m
> missing?~
For my own purposes, I''m planning on building a SCSI generic front- 
end/back-end driver pair to make SCSI disks available to domU''s.   
This driver would be available to the Xen community.

Since I''m not running Linux on the front-end, I hadn''t thought
much
about the major device number problem.  Instead, I''ve got an O/S that  
generates SCSI requests and I didn''t want to have to work very hard  
to try to translate them to blk requests: SES commands, test unit  
ready, serial number requests, etc.  In addition, our O/S uses  
scatter/gather lists extensively and I''d like to pass those along  
instead of buffering and copying data.

I figured I''d just rely on the SCSI generic driver to send my already- 
generated requests over the SCSI adapter to the devices on the bus.

Since I''ve never written a Xen driver before, my basic premise was to  
begin with a basic front-end talking to a back-end and adding  
functional components one at a time.  And, documenting my work for  
others to read.  Or, is there already good documentation somewhere on  
designing/building a front-end/back-end driver pair?

-- Randy

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

In article <1150802478.7727.6.camel@localhost.localdomain> you
wrote:
> I think bugzilla 625 is caused by compiling the scsi disk driver into
> the domU kernel.  xen_blk can''t then get the SCSI major number 8. 
This
> is a usability issue because people create broken domU kernels and then
> raise bugs.  What''s the best fix?  Changing the Kconfig files to
> prohibit built in scsi disk when blkfront is enabled?  Is there a better
> option?
Using Kconfig would be my first thought too, I''m not sure if there is a
better option. I ran into this problem myself the other day, took
me a while to work out what the case.



-- 
Horms                                           http://www.vergenet.net/~horms/


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel