Xen devel - Jan 2006 - [PATCH] xc_XXX_build - add parallel routines to support input via buffer rather than files

I have a need to pass image and ramdisk via buffers, and not files.  I added
some parallel routines so as not to disturb the existing APIs. This may, or
may not, have been the correct choice, but it works.  In this patch,
you''ll
find xc_linux_build_mem and xc_vmx_build_mem as the new interfaces, which
accept buffer pointer/size arguments rather than filename arguments. The old
interfaces remain (both in code and working status). Some internal shuffling
was needed to accomodate this, which I''ve tried to minimize.
I''ve tested
most of this, the expection being IA64, which I don''t have.

-b



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

I''d just like to add a +1 from me to the concept of an optional memory 
interface to the building APIs.  I implemented something similar for domU 
kexec support, and if something like this is available in the up-to-date 
tree, I won''t have to update that part of my original patch when we
update
the sparse tree to 2.6.15 ;-)

One suggestion based on my experience:
the interface to setup_guest would seem to be cleaner if it *always* assumed 
its taking inflated buffers for the initrd, as well as the kernel.  You can 
just load and inflate the initrd in in the builder function (if necessary!) 
as we do already for the kernel.

Would anyone object to this?  The interface to the rest of xc that you propose 
sounds like a step in the right direction.

Cheers,
Mark

On Monday 16 January 2006 21:05, B Thomas wrote:
> I have a need to pass image and ramdisk via buffers, and not files.  I
> added some parallel routines so as not to disturb the existing APIs. This
> may, or may not, have been the correct choice, but it works.  In this
> patch, you''ll find xc_linux_build_mem and xc_vmx_build_mem as the
new
> interfaces, which accept buffer pointer/size arguments rather than filename
> arguments. The old interfaces remain (both in code and working status).
> Some internal shuffling was needed to accomodate this, which I''ve
tried to
> minimize. I''ve tested most of this, the expection being IA64,
which I don''t
> have.
>
> -b
-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

Hi Mark,

You had asked about this patch, and I wanted to give you an update. 
I''ve
submitted it twice, the second time with your suggestions incorporated.  I
haven''t received any direct or indirect feedback or comment at this
point.
I haven''t submitted enough patches at this point to be sure whether
this
means anything or not. At this point, though, it appears that it''s not
incorporated into the source tree. On the other hand, other patches
I''ve
submitted have just shown up without fanfare at some later point.

I''m not sufficiently familiar with the xen-devel process and practices
to
know the line between helpful persistence and spamming the list, so at this
point I''m leaning towards not resubmitting it yet again.

I welcome any feedback and suggestions,
Thanks,
-b


On 1/16/06, Mark Williamson <mark.williamson@cl.cam.ac.uk>
wrote:
>
> I''d just like to add a +1 from me to the concept of an optional
memory
> interface to the building APIs.  I implemented something similar for domU
> kexec support, and if something like this is available in the up-to-date
> tree, I won''t have to update that part of my original patch when
we update
> the sparse tree to 2.6.15 ;-)
>
> One suggestion based on my experience:
> the interface to setup_guest would seem to be cleaner if it *always*
> assumed
> its taking inflated buffers for the initrd, as well as the kernel.  You
> can
> just load and inflate the initrd in in the builder function (if
> necessary!)
> as we do already for the kernel.
>
> Would anyone object to this?  The interface to the rest of xc that you
> propose
> sounds like a step in the right direction.
>
> Cheers,
> Mark
>
> On Monday 16 January 2006 21:05, B Thomas wrote:
> > I have a need to pass image and ramdisk via buffers, and not files.  I
> > added some parallel routines so as not to disturb the existing APIs.
> This
> > may, or may not, have been the correct choice, but it works.  In this
> > patch, you''ll find xc_linux_build_mem and xc_vmx_build_mem as
the new
> > interfaces, which accept buffer pointer/size arguments rather than
> filename
> > arguments. The old interfaces remain (both in code and working
status).
> > Some internal shuffling was needed to accomodate this, which
I''ve tried
> to
> > minimize. I''ve tested most of this, the expection being IA64,
which I
> don''t
> > have.
> >
> > -b
>
> --
> Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
> Mark: To answer a question with a question: What use is a skateboard?
> Dave: Skateboards have wheels.
> Mark: My wheel has a wheel!
>

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

>  You had asked about this patch, and I wanted to give you an update.  
> I''ve submitted it twice, the second time with your suggestions 
> incorporated.  I haven''t received any direct or indirect feedback
or
> comment at this point.  I haven''t submitted enough patches at this
> point to be sure whether this means anything or not. At this point, 
> though, it appears that it''s not incorporated into the source
tree. On
> the other hand, other patches I''ve submitted have just shown up 
> without fanfare at some later point.
>
>  I''m not sufficiently familiar with the xen-devel process and 
> practices to know the line between helpful persistence and spamming 
> the list, so at this point I''m leaning towards not resubmitting it
yet
> again.
The patch is fairly big and noone''s had time to pick it up and review 
and it and test it. If there are others who want this patch in it would 
be useful to get confirmation that it works for them, and that existing 
usages of the domain builder are not regressed.

  -- Keir


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