WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] RFC: Creation of virtual bus, hook-up of Xen devices

To: Jeremy Katz <katzj@xxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: Creation of virtual bus, hook-up of Xen devices
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 01 Feb 2005 23:53:57 +0000
Cc: Christian.Limpach@xxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Tue, 01 Feb 2005 23:57:02 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 01 Feb 2005 18:09:20 EST." <1107299360.6422.10.camel@xxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
 
> The problem is that you really want to be able to probe what devices are
> there without loading the module.  Otherwise, if you build the net
> device as a module, how do you know that there are net devices present?
> You can do load/unload but that's a little bit ugly (and racy since it
> involves removing modules).  

Yep, we certainly don't want to get into module
loading/unloading. It's probably reasonable to always load the
net/blkfront drivers when running on xen -- its perhaps best just
to build them into the kernel.
 
> Another thought would be to add a way to get a simple enumeration of
> devices with types.  That would then be able to be generic and used to
> register all the devices.  Doing that starts to involve some bigger
> interface changes, though, which I wanted to avoid at first.

We're already planing changes to the control messages that will
break compatibility with 2.0 tools, so its reasonable to discuss
further changes.

> > - have you tested suspend/resume?
> 
> Nope, the last time I tried suspend/resume with the copy of -unstable I
> was running against it wasn't working at all.  I need to pull up to
> current and then that should be easy enough to get in place.

I'm afraid its still broken in unstable as no-one has tided up
after the SMP guest changes. We need to extend the dom0_op to
enable the context of different VCPUs to be read out, and modify
the save restore code accordingly. We also need to ensure that
the suspend notifier does an smp_call_function to park
the other VCPUs for the suspend.
 
> > I think we need to address these issues before we proceed.
> 
> No question that things have to be done... but if there's not screaming
> at the basic approach, it's far easier for me to clean stuff afterwards
> than to clean stuff up and then have to rework it majorly.  

Yep, discussing the design in advance and sending patches early
is how we like to do things round here -- thanks!

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel