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

Re: [Xen-devel] New Xen boot infrastructure proposal



On Wed, 2013-05-22 at 17:34 +0200, Daniel Kiper wrote:
> On Wed, May 22, 2013 at 04:25:19PM +0100, Ian Campbell wrote:
> > On Wed, 2013-05-22 at 16:09 +0100, Ian Campbell wrote:
> > > On Wed, 2013-05-22 at 16:27 +0200, Daniel Kiper wrote:
> > > > On Tue, May 21, 2013 at 01:52:04PM +0100, Ian Campbell wrote:
> > > > > On Tue, 2013-05-21 at 03:36 -0700, Daniel Kiper wrote:
> > > > > > It means
> > > > > > that at this stage it is worth to create completely new
> > > > > > boot structure which is not linked so tightly with any boot
> > > > > > protocol. It should contain all needed stuff, be architecture
> > > > > > independent as much as possible and easily extensible.
> > > > >
> > > > > Is this proposal intended to form a protocol between the bootloader 
> > > > > and
> > > >
> > > > More or less.
> > >
> > > So we are expecting bootloaders to all implement this Xen specific,
> > ....
> >
> > actually, I'm confused, the other sub-threads here seem to suggest this
> > protocol is between the "preloader" bits of Xen and the main body of
> > Xen, which is the other alternative I gave.
> 
> Sorry for confusion. I put my reply in incorrect line. I think about
> protocol "between the "preloader" bits of Xen and the main body of Xen".

OK, thanks for clarifying ;-)

In that case my question (which I think others have raised) is why does
this need to be a complex extensible protocol at all? The two halves
here must surely be upgraded in sync and so both sides can be changed
whenever the data needs expanding. i.e. this is just struct boot_info,
which perhaps contains "struct arch_boot_info arch;"

Or perhaps I've just read more into what you are proposing than you were
actually proposing.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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