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

[Jeremy Katz <katzj@xxxxxxxxxx>]

On Wed, 2005-02-02 at 01:06 +0000, Christian Limpach wrote:
> On Tue, Feb 01, 2005 at 06:09:20PM -0500, Jeremy Katz wrote:
> > > Can you give more specific examples of tools which would use this? 
> > 
> > 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.
> 
> Is this where anaconda tells you it can't find a network device even
> if it's built into the kernel?

Related.  The requirement of it being modular is largely due to
silliness with not being able to tell if your PCI network card is bound
to a driver or not.  And actually, that should be able to be made a
little bit better (and thus, support proper drivers which are built-in
for odd cases)

> > > What information would be exported under devices/netN and
> > > devices/blkN?
> 
> Do you know yet what information would be exported?  Or is the existence
> of the netN/blkN devices sufficient for your immediate usage?

Existence is good enough for _my_ immediate needs, but it's probably not
the best in general or for the longer term.  If things can get to where
there's a unique identifier for every virtual device (which is probably
the better long term option), then a cleaner arrangement would probably
be
 /sys/bus/xen/devices
   devid1/
      class (file containing a class id for net, block, usb, ...)
      handle
      evtchn
      irq
      driver -> driver dir if driver is loaded

Then it can parallel other actual hardware buses a little bit more
closely.

> > > - 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.
> 
> So far we've used macros to either make the 2.6 calls do something
> useful in 2.4 or do nothing at all.

Okay, I'll have to look a little closer for that, then.  Tomorrow's todo
list begins :)

> > > - 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 :-)
> 
> I see.  x is just so very unspecific.  We're certainly happy with xen ;-)
> Maybe vmm would make sense?

Or maybe vmmio to be a little bit more descriptive.  Since I don't think
that things like memory, cpus, etc make sense on there and so it's
mostly for IO devices.

> > > 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).  
> 
> Ah I see.  How about you move the network probing code into a seperate file
> next to netfront.c and always include that in the kernel?  This would also
> take care of some of the 2.4 code sharing issues since 2.4 could then have
> a different file.  Not sure yet how best to avoid doing enumeration twice,
> it looks like we want an additional driver state or some probe only
> enumeration call.

That could work, although if the end direction is something akin to the
above, then it may make less sense to do this as an intermediate step.
If not, then it shouldn't be too hard to do. 

> I reckon my description wasn't 100% accurate after all -- I assumed that
> the probe hook was getting called as soon as the device was registered.
> That wouldn't make sense if the module is not loaded yet (and the probe
> function isn't known to the bus).  When does the probe function get
> called?

When the device gets registered, it gets added as a child of the bus
device.  device_register() uses bus->match to see if any of the loaded &
registered drivers can drive the device.  Since no drivers are loaded
when x_bus_init() gets called, the driver loads and registers later.  On
driver registration, the bus gets walked for unattached devices that
match the type the driver supports.  On a match, driver->probe is called
and the device and driver are bound.   

> > 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.
> 
> How do other devices handle this?  Isn't there a generic framework for
> this?  Or are you suggesting adding a non-xen specific framework?

It tends to be bus-specific as dictated by the hardware.  eg, for USB,
you get control messages that the host controller interprets and then
passes off as appropriate.  For PCI, you can walk a tree provided in a
host-specific way (BIOS/PIRQ tables or ACPI on x86, OpenFirmware on PPC,
etc).  So there would need to be a xen specific way of doing this or
making xen present something that looks like one of these other things.
I think that the approach that most mimics what the rest of the Xen
approach is would be to add a Xen specific way, though.

> > > 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.  
> 
> I think that the way how you hook device registration into the code
> which discovers devices (or vice versa) is the tricky part and needs
> to be decided upon early.

Agreed.  

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