On Thu, 2005-02-10 at 00:17 +0000, Christian Limpach wrote:
>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.
After getting some work done, one problem is there's not a
device-type-independent device id for each device (or if so, I'm missing
it entirely :). I can get type + index to get an identifier, but that's
not generic across all the devices. That's not a huge stumbling block,
though, as it's at least _a_ unique identifier.
I'm also not sure how things interact as far as device indexing after
suspend of a guest since that's not working in -unstable.
>> > > > - 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.
I think the general handling of hotplug cpus and memory in Linux right
now falls into the category of "poor". :-) I'll go with vmm, though,
to keep it generic enough for exposing cpu and memory via it if that
makes sense in the future.
>> 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.
Yes, changing to probe only doing the enumeration of devices. And then,
loading the driver really only has to connect to the devices and set
their status. You're right on it not being that difficult once I got a
better feeling of my way around the maze of calls in xend and how they
interact.
This also adds the advantage that instead of having to do a complete
rescan for adding a new device (right now, adding a device ends up
sending an INTERFACE_CHANGED message and the burden is then on the
frontend drivers to determine exactly what that entails), you can just
send a message that says "new block device, index 2" and that gets
matched to a driver and the driver only needs to change things for that
device.
>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.
Well, there are three now with USB. And requiring the guest kernels to
know it all seems silly. It's actually pretty simple to do in a generic
fashion.
>Have you made any progress on this?
Not as much as I would _like_ to have, just due to some other things
keeping me busy but I am making slow but steady progress. My plan is to
try to work on it some more tonight and hopefully get a next iteration
out for more comments in the next day or so.
Jeremy
-------------------------------------------------------
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
|
Home