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

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


  • To: Jeremy Katz <katzj@xxxxxxxxxx>
  • From: Christian Limpach <christian.limpach@xxxxxxxxx>
  • Date: Tue, 1 Feb 2005 22:49:04 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 01 Feb 2005 22:51:36 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=kYJ3K1QQXPSf+4ts2bYOcA9nRpLnXzMQ6K4sDC9N9Hktz8UsHKXzMfgGBQAIa+eS2Z2Fv4zqhQXFL2UGnBgq0sVz/rAGUKdOssRDS+0CVYNO4wDI2CmBtAhjE2ymdNowTNQnrGYBB8OoL7NaCtSblQTvlq9PmfMMEqArBS7AJa0=
  • List-id: List for Xen developers <xen-devel.lists.sourceforge.net>

On Tue, 01 Feb 2005 15:30:51 -0500, Jeremy Katz <katzj@xxxxxxxxxx> wrote:
> For many purposes on a Linux system, it is required to have devices
> export themselves via the device infrastructure (exposed via sysfs) to
> allow for reasonable user-space probing and discovery of available
> devices.  This is especially useful/necessary for things like installing
> to guest systems.

Can you give more specific examples of tools which would use this? 
What information would be exported under devices/netN and
devices/blkN?

Having support for the device infrastructure is good - thanks for the patch.

> Comments?

There's a few issues with the patch:
- netfront.c is shared between linux 2.6 and 2.4 and it's not going to
build on 2.4 with the changes.  same for blkfront.c.
- wouldn't /sys/bus/xen be a better name than /sys/bus/x?
- same for exported functions, x_register_driver et al. are IMHO too
general and pollute the namespace -- I'd suggest prefixing everything
with xenbus, incl the structs which get defined in xbus.h (xenbus.h).

- if I understand the change to the network probing code correctly, it
relies on xbus_init getting called before netif_init.  xbus_init will
change the driver status up and then down again, causing the network
devices to get enumerated and register the network devices during this
enumeration.  I assume that the call to device_register from
x_register_device then causes the poll hook to get called which
creates the device struct.  netif_init will then change the driver
status up again and cause another enumeration which then puts the vif
into connected state.
You've already noted that the network probing code doesn't belong in
the xbus code.  We also don't want the additional driver status
changes.  Wouldn't it just work to call xenbus_register_device in the
interface status message handler?

- have you tested suspend/resume?

I think we need to address these issues before we proceed.

     christian


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.