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

Re: [Xen-devel] AHCI question


  • To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  • From: Kamala Narasimhan <kamala.narasimhan@xxxxxxxxx>
  • Date: Tue, 23 Nov 2010 11:45:29 -0500
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 23 Nov 2010 08:46:24 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WVGSUbod8JWz/jeeKlV2rquRE3byDJeYaQ4Jv7GcF4AgUeipb0hR3dUf1+C3xkm5it t8W21q/5jK+NVK4GNHf6h1mxpG+7Smy9W5MgbvgM8aP3tpNPQ7JErfeE/0RxdrDGpiKI l45DcdcmnK134MjNZPdkk8/gxWMAB7XPC4eCI=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

> I think you are better of asking on the ahci-devel, and as well folks
> on the kdump mailing list as they had to wrestle with these kinds of
> issues already.

Is there a ahci-devel list I am unaware of?  In the mean time, I
managed to pepper some of the Linux storage list with the same
question.  No dice yet.

>
> Thought .. why not use the kdump kernel?

Per folks more knowledgeable in kdump/kexec etc., here are some advantages -

1) This approach doesn't have the same resource constraint as that of
kdump approach like setting aside memory.
2) This would be more reliable on systems that uses AHCI.

Also, in the long run this component could be turned into one of the
many lowest level pluggable storage interface for crash dump
persistence and other components could be built on top to collect lot
more useful information.

Kamala

_______________________________________________
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®.