All of lore.kernel.org
 help / color / mirror / Atom feed
* 3.0.3 Status/Schedule
@ 2006-06-09 15:37 Ben Thomas
  0 siblings, 0 replies; 3+ messages in thread
From: Ben Thomas @ 2006-06-09 15:37 UTC (permalink / raw)
  To: xen-devel

Curiousity prompts me to inquire about the 3.0.3 schedule and status.

3.0.1 was announced on 2/1/2006
3.0.2 was announced on 4/13/2006

and I recall something about a roughly 6-8 week (or so) schedule
delta.  That would mean 3.0.3 might be on the horizon. Hence
my curiousity, and this email.

Thanks,
-b

-- 
------------------------------------------------------------------------
Ben Thomas                                         Virtual Iron Software
bthomas@virtualiron.com                            Tower 1, Floor 2
978-849-1214                                       900 Chelmsford Street
                                                    Lowell, MA 01851

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: 3.0.3 Status/Schedule
@ 2006-06-10 13:02 Ian Pratt
  2006-06-14  3:17 ` Horms
  0 siblings, 1 reply; 3+ messages in thread
From: Ian Pratt @ 2006-06-10 13:02 UTC (permalink / raw)
  To: Ben Thomas, xen-devel

> Curiousity prompts me to inquire about the 3.0.3 schedule and status.
> 
> 3.0.1 was announced on 2/1/2006
> 3.0.2 was announced on 4/13/2006
> 
> and I recall something about a roughly 6-8 week (or so) schedule
> delta.  That would mean 3.0.3 might be on the horizon. Hence
> my curiousity, and this email.

The current plan is to shoot for 3.0.3 in the 2nd week July, which fits
in with the FC6 schedule, and ahead of many developer's trips to Ottawa
for OLS.

Things I'd ideally still like to see get included:

 * new 'credit' CPU scheduler as default (need more testing -- known HVM
bug under investigation)
 * cow file-backed virtual hard disk support (dm-userspace or blktap
patches)
 * qemu-dm updated to latest qemu version, stored as patch queue
(getting there)
 * xend VM lifecycle management patches (I'm told this is almost ready
for posting)
 * basic NUMA memory allocator support (we seem close on this)
 * kexec support (this looks better every iteration)

Ian  

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 3.0.3 Status/Schedule
  2006-06-10 13:02 Ian Pratt
@ 2006-06-14  3:17 ` Horms
  0 siblings, 0 replies; 3+ messages in thread
From: Horms @ 2006-06-14  3:17 UTC (permalink / raw)
  To: Ian Pratt; +Cc: Ben Thomas, xen-devel

In article <A95E2296287EAD4EB592B5DEEFCE0E9D4BAA45@liverpoolst.ad.cl.cam.ac.uk> you wrote:
>> Curiousity prompts me to inquire about the 3.0.3 schedule and status.
>> 
>> 3.0.1 was announced on 2/1/2006
>> 3.0.2 was announced on 4/13/2006
>> 
>> and I recall something about a roughly 6-8 week (or so) schedule
>> delta.  That would mean 3.0.3 might be on the horizon. Hence
>> my curiousity, and this email.
> 
> The current plan is to shoot for 3.0.3 in the 2nd week July, which fits
> in with the FC6 schedule, and ahead of many developer's trips to Ottawa
> for OLS.
> 
> Things I'd ideally still like to see get included:
> 
> * new 'credit' CPU scheduler as default (need more testing -- known HVM
> bug under investigation)
> * cow file-backed virtual hard disk support (dm-userspace or blktap
> patches)
> * qemu-dm updated to latest qemu version, stored as patch queue
> (getting there)
> * xend VM lifecycle management patches (I'm told this is almost ready
> for posting)
> * basic NUMA memory allocator support (we seem close on this)
> * kexec support (this looks better every iteration)

I haven't posted an update of kexec for a while for several reasons,
mainly relating to me and my colleague Magnus spending a lot of time
away from our desks of late or dealing with other (internal) tasks.
I appologise for that.

I'd like to get an idea of what problems with kexec you (or anyone else)
would like to see addressed for 3.0.3 so energy can be focused
accordingly. This includes breaking up the patches further to aid review
if that is desirable. Time on this side is tight between now and OLS,
so I'd like to make the most of the cycles we have.

Right now I only have one change in my tree, which is
a Kconfig change to prevent kexec from compiling for DomU. I can send
that ASAP, or hold off until something more substantial materialises.
Let me know.

Here is what I believe is the current status of kexec/kdump on xen.

  x86_32: kexec: works
          kdump: works
	  vmcore: need to expose dom0, and possibly domU cr3.
	          This is being discussed on the crash mailing list,
	  	but clearly affects only kdump not kexec.
	  https://www.redhat.com/archives/crash-utility/2006-June/msg00008.html

  x86_64: kexec: works
            - actually it only works on some x86_64, but the same problem
	      exists in linux kexec, so its not a problem with the port as
	      such. Just something that needs more testing and fixing for
	      both linux and xen
          kdump: not implemented
	    - in particular shutdown and register handling needs to be
	      implemented. This is not a huge task, Magnus and I just
	      havn't had enough time to get to it

  ia64: still not started, but kdump is looking more solid in linux now
        and that is a tremendous help.

	http://lists.osdl.org/pipermail/fastboot/2006-June/003091.html

Lastly, if anyone has comments, suggestions or patches relating to
the kexec patches that I have sent, please don't hesitate to send
them here, CCed to me. The more contributors the merrier.

-- 
Horms                                           http://www.vergenet.net/~horms/

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-06-14  3:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-09 15:37 3.0.3 Status/Schedule Ben Thomas
  -- strict thread matches above, loose matches on Subject: below --
2006-06-10 13:02 Ian Pratt
2006-06-14  3:17 ` Horms

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.