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

[Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>]

On Tue, Feb 01, 2005 at 09:20:20PM -0500, Jeremy Katz wrote:
> > > > 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.

OK, sounds good.

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

Actually, we might want to add memory and cpus, or is there another
abstraction to represent hotplug cpus and memory?  I think xen or vmm
would be good names, I've used hypervisor in NetBSD.

> > > > 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'm not 100% sure what you mean by end direction?  Do you mean the change
to a probe only enumeration call?  I think that would be a simple change
since the call would be very similar on the client side, but it would
allow the backend to skip any changes which are only required when the
device is actually brought up.

> > > 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 you want to query each backend and find out what devices it has.
I'm not sure if the enumeration function should be generic or
device-specific.  Our current device-specific approach could probably be
changed to be generic but in a first instance it would be quickest to
implement this using the existing "queries" since there are only two
device types.

Have you made any progress on this?

    christian



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel