Xen devel - Jul 2005 - [PATCH] Support for official xvd major number

LANANA has officially assigned the block major of 202 for xvd devices
(http://www.lanana.org/docs/device-list/devices-2.6+.txt).  Take
advantage of knowing this so people don''t have to do the mknod on their
system.  Also, fix up the scsi regex to get sda correct without having
to do hacks like sda0.

Signed-off-by: Jeremy Katz <katzj@redhat.com>

Jeremy


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

On Thu, 2005-07-14 at 17:15 -0400, Jeremy Katz wrote:
> LANANA has officially assigned the block major of 202 for xvd devices
> (http://www.lanana.org/docs/device-list/devices-2.6+.txt).  Take
> advantage of knowing this so people don''t have to do the mknod on
their
> system.  Also, fix up the scsi regex to get sda correct without having
> to do hacks like sda0.
Also, on a side note that is really unrelated to the patch, is there
really a good reason why these hoops are still gone through instead of
having the kernel allocate the next disk instead of the hard-coding with
things somewhat out of order and stealing the major/minors of other
subsystems?

Jeremy


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

On 14 Jul 2005, at 22:35, Jeremy Katz wrote:
> Also, on a side note that is really unrelated to the patch, is there
> really a good reason why these hoops are still gone through instead of
> having the kernel allocate the next disk instead of the hard-coding 
> with
> things somewhat out of order and stealing the major/minors of other
> subsystems?
I''m not sure what you mean? Specifying device numbers up front in a 
config file means that you know e.g., what device names to put in your 
fstab and what to specify as your rootfs device. And stealing scsi/ide 
device names/numbers is the strategy of least surprise to userspace 
tools and scripts (e.g., some vendor init scripts have a baby if 
filesystems are mounted on a weirdly-named block device like xvd<foo>). 
And the xvd* names and numbers are there if you want to avoid clashes 
with other subsystems.

  -- Keir


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

On Thu, 2005-07-14 at 22:38 +0100, Keir Fraser wrote:
> On 14 Jul 2005, at 22:35, Jeremy Katz wrote:
> > Also, on a side note that is really unrelated to the patch, is there
> > really a good reason why these hoops are still gone through instead of
> > having the kernel allocate the next disk instead of the hard-coding 
> > with
> > things somewhat out of order and stealing the major/minors of other
> > subsystems?
> 
> I''m not sure what you mean? Specifying device numbers up front in
a
> config file means that you know e.g., what device names to put in your 
> fstab and what to specify as your rootfs device. 
Your first disk should get registered first and be xvda, your second
xvdb, etc.  If you''re afraid of the order changing, you should be using
label or uuid to mount.  The same questions come up with physical
devices.
> And stealing scsi/ide 
> device names/numbers is the strategy of least surprise to userspace 
> tools and scripts (e.g., some vendor init scripts have a baby if 
> filesystems are mounted on a weirdly-named block device like
xvd<foo>).
Those scripts are broken and are going to break with a fair bit of other
hardware too.  There are more of these "weird" block devices being
added
and not less.  And as it stands now, if something sees "scsi disk" and
then tries to do any checks with /proc/scsi, they''re going to fail.  So
there are common things that get broken with both.

Jeremy


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

Hi,

Rumor has it that on Thu, Jul 14, 2005 at 05:57:58PM -0400 Jeremy Katz
said:
> On Thu, 2005-07-14 at 22:38 +0100, Keir Fraser wrote:
> > On 14 Jul 2005, at 22:35, Jeremy Katz wrote:
> > > Also, on a side note that is really unrelated to the patch, is
there
> > > really a good reason why these hoops are still gone through
instead of
> > > having the kernel allocate the next disk instead of the
hard-coding
> > > with
> > > things somewhat out of order and stealing the major/minors of
other
> > > subsystems?
> > 
> > I''m not sure what you mean? Specifying device numbers up
front in a
> > config file means that you know e.g., what device names to put in your
> > fstab and what to specify as your rootfs device. 
> 
> Your first disk should get registered first and be xvda, your second
> xvdb, etc.  If you''re afraid of the order changing, you should be
using
> label or uuid to mount.  The same questions come up with physical
> devices.
In a virtualized world where your block device can be moved from
system to system in software using labels is unwise. When your 
disk is internal it''s not really a problem, but when you move disks 
around easily the labels get in the way. Duplicate "/" will keep your 
system from booting. The label thing is basically a hack to get around 
the brain dead device naming in linux. The hda/hdb/hdc thing only
makes sense for internal IDE disks and even then you have issues now
that sata shows up the same way. It''s too bad the original linux scsi
implementation followed this model.

There''s no reason to enforce that first-in ordering for xvd devices
that I can see. Specify where you want the device to show up and then
access it there. 

Physical devices do have the same issues, but those are really solved 
by using udev (and helpers like scsi_id) not fs labels and uuids. Besides, 
labels are only useful if you have a filesystem on that block device. 
Not all block devices have file systems...


Cheers,

Phil

-- 
Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752

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