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

[Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>]

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?

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

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

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

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

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?

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

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

Yes, suspend/resume is broken in -unstable.

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

    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