Re: [XenPPC] JS21/SLOF net boot commands

[Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>]

> I posted these "hacks", because people were asking me how I loaded  
> images separately on this machine.
And much appreciated, from my side anyway.

> There is no architected design, just another hack for a  
> insufficient loading environment for a specific development  
> environment.
Hey, it gets better, I'm just slow heh.

> Except for the "load anywhere" argument, which I would like to see  
> eventually, you guys are FOS.
Current SLOF isn't open source, sigh.  And I can't discuss the
where or how or what, so please drop the argument.

> There is a Xen work-a-round for every single issue you guys raise,
Who is "you guys"?  The SLOF people?  We don't raise the problems,
we just cause them.  And we _do_ try to help you out.  Or stuff isn't
perfect yet, that's just the eventual goal.  Blame it on job security,
if you want to blame it on anything.

And yes, there is a work-around at every level of the stack, always;
and if there is a sort-of reasonable workaround at _your_ level of the
stack, you should implement it.  Help yourself, in the true "FOS"  
spirit.
If the actual problem is at "my" level of the stack, you should of  
course
raise the issue with my team.  It might take a while before its solved
at our level of course, esp. if it's a new feature for us.

> I'm just describing a way that accelerate the boot process over a  
> network on a specific piece of HW.
> In a production environment with SLOF, a bootloader will obtain n  
> images (2 for yaboot, N for grub) from the disk, which is a runtime  
> IO method SLOF supports.
My point here was that those N images will be instantiated at fixed
memory locations, which can *never* (portably) work, given the PowerPC
OF binding.  Or, the first image would have to claim memory for all
of them, and "load" should only be used for the first, hard "read"
and "write" after that (and then, you cannot find out the size of those
later images before reading them!)


Segher


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