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: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: Creation of virtual bus, hook-up of Xen devices
From: Jeremy Katz <katzj@xxxxxxxxxx>
Date: Tue, 01 Feb 2005 20:13:03 -0500
Cc: Christian.Limpach@xxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 02 Feb 2005 01:16:40 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <E1Cw7qI-0004Nn-00@xxxxxxxxxxxxxxxxx>
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>
References: <E1Cw7qI-0004Nn-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
On Tue, 2005-02-01 at 23:53 +0000, Ian Pratt wrote:
>  > 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.

Well, you want modules just so that things "look like" everywhere else.
The route of built-in with one kernel and modular on another leads to
madness eventually.  That doesn't necessarily mean they need to be
unloadable (it's easy enough to permanently refcount a module, and it's
not unheard of), but if they're not, you probably do want to be able to
tell what's there
 
> > 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.

That was the impression I got.  Really, adding a generic "added a net
device, it's handle is x", "added a block device, it's handle is y", ...
etc[1] is probably the easiest way to do this.  It also then interacts
nicely for hotplug as you have the bus do all the matching and then it
just hands off the struct device to the appropriate driver's ->probe
function.  Which then lets you have the tools in dom0 support more
devices than you have backend drivers in the guest for without ill
effect (and you could even still have the devices in your device tree so
that if you then built a module in domU, it could claim those
devices).  

Jeremy

[1] Okay, doing a numeric type instead of a string is slightly prettier,
but for the sake of argument



-------------------------------------------------------
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