[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Disk naming (Was Re: [Xen-devel] [PATCH] Guestbootloadersupport [1/2])


  • To: "Jeremy Katz" <katzj@xxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Thu, 14 Apr 2005 23:02:11 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 14 Apr 2005 22:02:05 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcVBO5jTvg/o9bNGRDCihIiRo5IIsQAAW5Iw
  • Thread-topic: Disk naming (Was Re: [Xen-devel] [PATCH] Guestbootloadersupport [1/2])

> Keeping it working in the short-term while people want to do 
> this might be reasonable, but if they're doing the Right (tm) 
> thing and mounting by label or uuid, it doesn't matter what 
> the device is.  And I think that medium term, there are going 
> to be plenty of other changes needed for going from a native 
> system to an unprivileged guests.  

You'd be surprised -- I do this quite frequently, and although you get a
lot of grumbles during the boot scripts, it does just work.

> http://www.lanana.org/docs/device-list/instructions.txt has 
> the instructions.  I can volunteer to send the information 
> upstream.  It looks like using xd is already going to be a 
> namespace conflict with the ooollldddd IDE devices, though.  
> What if we go with vbd for the device names?  Then the questions are

Is the fact that it's 3 chars rather than 2 going to cause problems?
vda1 ?

> a) How many minors per disk device?  This dictates number of 
> partitions.
> It's probably reasonable to just do 15 like SCSI (especially 
> as more can then be handled dynamically for 2.6)

15 sounds fine.

> b) How many vbds do we want to have static majors for?  16 is 
> probably reasonable and this then means that we only take up 
> a single block minor.

Yep.


Ian

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.