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

[Jeremy Katz <katzj@xxxxxxxxxx>]

On Tue, 2005-02-01 at 22:49 +0000, Christian Limpach wrote:
> 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?

kudzu (and thus anaconda) and hal both immediately spring to mind.
anaconda being the one that's near and dear to me ;)

I want to get to where I can install inside a guest and have it be
virtually identical to installation on hardware.  Different drivers is
fine but probing is still useful.

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

I thought that was the case.  Like I said, this is really a first pass
just to get something to look at since I think it's far more concrete
and less hand-wavey with some code to look at.  Although to really fully
take advantage of some of the stuff in 2.6, I'm not entirely sure how to
keep this in sync.

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

s/x/xen/ is easy enough to do.  Although not as xen leaves it more open
for other virtualization frameworks to eventually use the same model.
The idea of sub_x_bus also came up just from the nice anagram it would
give :-)

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

Exactly.

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

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

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.

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

Jeremy



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