* KVM call agenda for Tuesday 7 @ 2012-02-06 19:25 ` Juan Quintela 0 siblings, 0 replies; 31+ messages in thread From: Juan Quintela @ 2012-02-06 19:25 UTC (permalink / raw) To: KVM devel mailing list, Developers qemu-devel Hi Please send in any agenda items you are interested in covering. Cheers, Juan. ^ permalink raw reply [flat|nested] 31+ messages in thread
* [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-06 19:25 ` Juan Quintela 0 siblings, 0 replies; 31+ messages in thread From: Juan Quintela @ 2012-02-06 19:25 UTC (permalink / raw) To: KVM devel mailing list, Developers qemu-devel Hi Please send in any agenda items you are interested in covering. Cheers, Juan. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-06 19:25 ` [Qemu-devel] " Juan Quintela @ 2012-02-07 13:45 ` Andreas Färber -1 siblings, 0 replies; 31+ messages in thread From: Andreas Färber @ 2012-02-07 13:45 UTC (permalink / raw) To: quintela, Anthony Liguori; +Cc: KVM devel mailing list, Developers qemu-devel Am 06.02.2012 20:25, schrieb Juan Quintela: > Please send in any agenda items you are interested in covering. I had some follow-up questions to the last call that remained unanswered. We don't really need a call for that though, email is fine. http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html How is the realize step (DeviceState::init) supposed to translate to Object-derived classes (e.g., CPU) and where to draw the line between initfn and realize. For virtual methods Anthony outlined the intended scheme here: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00622.html (Derived classes should save the parent's function pointer in their own Class and initialize it from the parent class' function pointer.) Another topic that can be answered by email is what the time planning for the 4th QOM series looks like. Are there things that developers of new devices should keep in mind / start doing differently wrt SysBus? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 13:45 ` Andreas Färber 0 siblings, 0 replies; 31+ messages in thread From: Andreas Färber @ 2012-02-07 13:45 UTC (permalink / raw) To: quintela, Anthony Liguori; +Cc: Developers qemu-devel, KVM devel mailing list Am 06.02.2012 20:25, schrieb Juan Quintela: > Please send in any agenda items you are interested in covering. I had some follow-up questions to the last call that remained unanswered. We don't really need a call for that though, email is fine. http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html How is the realize step (DeviceState::init) supposed to translate to Object-derived classes (e.g., CPU) and where to draw the line between initfn and realize. For virtual methods Anthony outlined the intended scheme here: http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00622.html (Derived classes should save the parent's function pointer in their own Class and initialize it from the parent class' function pointer.) Another topic that can be answered by email is what the time planning for the 4th QOM series looks like. Are there things that developers of new devices should keep in mind / start doing differently wrt SysBus? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 13:45 ` Andreas Färber @ 2012-02-07 13:52 ` Paolo Bonzini -1 siblings, 0 replies; 31+ messages in thread From: Paolo Bonzini @ 2012-02-07 13:52 UTC (permalink / raw) To: Andreas Färber Cc: quintela, Anthony Liguori, KVM devel mailing list, Developers qemu-devel On 02/07/2012 02:45 PM, Andreas Färber wrote: > Another topic that can be answered by email is what the time planning > for the 4th QOM series looks like. Are there things that developers of > new devices should keep in mind / start doing differently wrt SysBus? Another related question is, should the 4th QOM series present a full composition tree based on the legacy qdev bus concept? Currently it doesn't, but if not, why not? That would help _a lot_ with removing PROP_PTR. Paolo ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 13:52 ` Paolo Bonzini 0 siblings, 0 replies; 31+ messages in thread From: Paolo Bonzini @ 2012-02-07 13:52 UTC (permalink / raw) To: Andreas Färber Cc: Developers qemu-devel, KVM devel mailing list, quintela On 02/07/2012 02:45 PM, Andreas Färber wrote: > Another topic that can be answered by email is what the time planning > for the 4th QOM series looks like. Are there things that developers of > new devices should keep in mind / start doing differently wrt SysBus? Another related question is, should the 4th QOM series present a full composition tree based on the legacy qdev bus concept? Currently it doesn't, but if not, why not? That would help _a lot_ with removing PROP_PTR. Paolo ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 13:52 ` Paolo Bonzini @ 2012-02-07 14:56 ` Anthony Liguori -1 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 14:56 UTC (permalink / raw) To: Paolo Bonzini Cc: Andreas Färber, Developers qemu-devel, KVM devel mailing list, quintela On 02/07/2012 07:52 AM, Paolo Bonzini wrote: > On 02/07/2012 02:45 PM, Andreas Färber wrote: >> Another topic that can be answered by email is what the time planning >> for the 4th QOM series looks like. qom-upstream.16 is pretty close to ready to be sent out for v1. It's fairly tricky getting these things into a bisectable state. I think I've got about a days worth of work left so hopefully in terms of calendar time, probably this friday. In terms of merging, once it's gotten the appropriate reviews. This won't be a rebase-pain so we'll just treat it like a normal series. >> Are there things that developers of >> new devices should keep in mind / start doing differently wrt SysBus? It's probably a good time to read object.h if you haven't already. In terms of deprecating things, I'd prefer to deprecate by removing which basically means we'd only deprecate SysBus after converting all of the current users. A big consideration at this point is compatibility. It's not clear to me what interfaces we really have to maintain compatibility for. For instance, the 4th series breaks setting -global properties based on bus name. But this is 1) not used by libvirt 2) not actually documented anywhere and 3) such a subtle implementation detail that I don't think more than a few people even know it's possible. > Another related question is, should the 4th QOM series present a full > composition tree based on the legacy qdev bus concept? Composition, no. The legacy qbus concept doesn't model composition because it puts children created by composition (like the Cirrus VGA adapter) in the same context as a device created by a user (like an e1000 network card). > Currently it doesn't, but > if not, why not? That would help _a lot_ with removing PROP_PTR. One thing that we could do, is modify qdev_create() like: DeviceState *qdev_create_with_name(BusState *bus, const char *typename, const char *name) { // ... object_property_add_child(legacy_machine_root(), name, OBJECT(dev), &err); // assert if err due to conflicting property names } DeviceState *qdev_create(BusState *bus, const char *typename) { return qdev_create_with_name(bus, typename, typename); } Most devices only have a single instance. In the cases where there are multiple instances, we'll have to fix it up manually but that really shouldn't be all that hard. That gives us composition paths and a clear goal for removing the legacy paths (we'd want to work toward eliminating /legacy-machine). device_add doesn't use qdev_create() and neither would properly refactored devices (they'd use object_init). Regards. Anthony Liguori > Paolo > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 14:56 ` Anthony Liguori 0 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 14:56 UTC (permalink / raw) To: Paolo Bonzini Cc: quintela, Andreas Färber, KVM devel mailing list, Developers qemu-devel On 02/07/2012 07:52 AM, Paolo Bonzini wrote: > On 02/07/2012 02:45 PM, Andreas Färber wrote: >> Another topic that can be answered by email is what the time planning >> for the 4th QOM series looks like. qom-upstream.16 is pretty close to ready to be sent out for v1. It's fairly tricky getting these things into a bisectable state. I think I've got about a days worth of work left so hopefully in terms of calendar time, probably this friday. In terms of merging, once it's gotten the appropriate reviews. This won't be a rebase-pain so we'll just treat it like a normal series. >> Are there things that developers of >> new devices should keep in mind / start doing differently wrt SysBus? It's probably a good time to read object.h if you haven't already. In terms of deprecating things, I'd prefer to deprecate by removing which basically means we'd only deprecate SysBus after converting all of the current users. A big consideration at this point is compatibility. It's not clear to me what interfaces we really have to maintain compatibility for. For instance, the 4th series breaks setting -global properties based on bus name. But this is 1) not used by libvirt 2) not actually documented anywhere and 3) such a subtle implementation detail that I don't think more than a few people even know it's possible. > Another related question is, should the 4th QOM series present a full > composition tree based on the legacy qdev bus concept? Composition, no. The legacy qbus concept doesn't model composition because it puts children created by composition (like the Cirrus VGA adapter) in the same context as a device created by a user (like an e1000 network card). > Currently it doesn't, but > if not, why not? That would help _a lot_ with removing PROP_PTR. One thing that we could do, is modify qdev_create() like: DeviceState *qdev_create_with_name(BusState *bus, const char *typename, const char *name) { // ... object_property_add_child(legacy_machine_root(), name, OBJECT(dev), &err); // assert if err due to conflicting property names } DeviceState *qdev_create(BusState *bus, const char *typename) { return qdev_create_with_name(bus, typename, typename); } Most devices only have a single instance. In the cases where there are multiple instances, we'll have to fix it up manually but that really shouldn't be all that hard. That gives us composition paths and a clear goal for removing the legacy paths (we'd want to work toward eliminating /legacy-machine). device_add doesn't use qdev_create() and neither would properly refactored devices (they'd use object_init). Regards. Anthony Liguori > Paolo > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 14:56 ` Anthony Liguori @ 2012-02-07 15:21 ` Paolo Bonzini -1 siblings, 0 replies; 31+ messages in thread From: Paolo Bonzini @ 2012-02-07 15:21 UTC (permalink / raw) To: Anthony Liguori Cc: Andreas Färber, Developers qemu-devel, KVM devel mailing list, quintela On 02/07/2012 03:56 PM, Anthony Liguori wrote: >> Another related question is, should the 4th QOM series present a full >> composition tree based on the legacy qdev bus concept? > > Composition, no. The legacy qbus concept doesn't model composition > because it puts children created by composition (like the Cirrus VGA > adapter) in the same context as a device created by a user (like an > e1000 network card). > >> Currently it doesn't, but >> if not, why not? That would help _a lot_ with removing PROP_PTR. > > One thing that we could do, is modify qdev_create() like: > > DeviceState *qdev_create_with_name(BusState *bus, const char *typename, > const char *name) > { > // ... > object_property_add_child(legacy_machine_root(), name, OBJECT(dev), &err); > // assert if err due to conflicting property names > } > > DeviceState *qdev_create(BusState *bus, const char *typename) > { > return qdev_create_with_name(bus, typename, typename); > } > > Most devices only have a single instance. In the cases where there are > multiple instances, we'll have to fix it up manually but that really > shouldn't be all that hard. I'm wary of all plans that require to go through all the code once. What about simply /devices/default/child[...] or something like that? BTW, I would like to change /i440fx to /devices/i440fx, so that we will have clean namespaces: /block ... /chardev ... /clocks ... /devices /peripheral ... # named devices created with -device /peripheral-anon /child[...] # unnamed devices created with -device /default /child[...] # created with qdev_create Paolo ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 15:21 ` Paolo Bonzini 0 siblings, 0 replies; 31+ messages in thread From: Paolo Bonzini @ 2012-02-07 15:21 UTC (permalink / raw) To: Anthony Liguori Cc: quintela, Andreas Färber, KVM devel mailing list, Developers qemu-devel On 02/07/2012 03:56 PM, Anthony Liguori wrote: >> Another related question is, should the 4th QOM series present a full >> composition tree based on the legacy qdev bus concept? > > Composition, no. The legacy qbus concept doesn't model composition > because it puts children created by composition (like the Cirrus VGA > adapter) in the same context as a device created by a user (like an > e1000 network card). > >> Currently it doesn't, but >> if not, why not? That would help _a lot_ with removing PROP_PTR. > > One thing that we could do, is modify qdev_create() like: > > DeviceState *qdev_create_with_name(BusState *bus, const char *typename, > const char *name) > { > // ... > object_property_add_child(legacy_machine_root(), name, OBJECT(dev), &err); > // assert if err due to conflicting property names > } > > DeviceState *qdev_create(BusState *bus, const char *typename) > { > return qdev_create_with_name(bus, typename, typename); > } > > Most devices only have a single instance. In the cases where there are > multiple instances, we'll have to fix it up manually but that really > shouldn't be all that hard. I'm wary of all plans that require to go through all the code once. What about simply /devices/default/child[...] or something like that? BTW, I would like to change /i440fx to /devices/i440fx, so that we will have clean namespaces: /block ... /chardev ... /clocks ... /devices /peripheral ... # named devices created with -device /peripheral-anon /child[...] # unnamed devices created with -device /default /child[...] # created with qdev_create Paolo ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 15:21 ` Paolo Bonzini @ 2012-02-07 16:24 ` Anthony Liguori -1 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 16:24 UTC (permalink / raw) To: Paolo Bonzini Cc: quintela, Andreas Färber, KVM devel mailing list, Developers qemu-devel On 02/07/2012 09:21 AM, Paolo Bonzini wrote: > On 02/07/2012 03:56 PM, Anthony Liguori wrote: >>> Another related question is, should the 4th QOM series present a full >>> composition tree based on the legacy qdev bus concept? >> >> Composition, no. The legacy qbus concept doesn't model composition >> because it puts children created by composition (like the Cirrus VGA >> adapter) in the same context as a device created by a user (like an >> e1000 network card). >> >>> Currently it doesn't, but >>> if not, why not? That would help _a lot_ with removing PROP_PTR. >> >> One thing that we could do, is modify qdev_create() like: >> >> DeviceState *qdev_create_with_name(BusState *bus, const char *typename, >> const char *name) >> { >> // ... >> object_property_add_child(legacy_machine_root(), name, OBJECT(dev), &err); >> // assert if err due to conflicting property names >> } >> >> DeviceState *qdev_create(BusState *bus, const char *typename) >> { >> return qdev_create_with_name(bus, typename, typename); >> } >> >> Most devices only have a single instance. In the cases where there are >> multiple instances, we'll have to fix it up manually but that really >> shouldn't be all that hard. > > I'm wary of all plans that require to go through all the code once. What about > simply /devices/default/child[...] or something like that? The paths would be unstable, but maybe that's okay. I'd suggest doing child[rand()] to avoid the appearance that these paths are in any way shape or form stable. > BTW, I would like to change /i440fx to /devices/i440fx, so that we will have > clean namespaces: > > /block > ... > /chardev > ... > /clocks > ... > /devices > /peripheral > ... # named devices created with -device > /peripheral-anon > /child[...] # unnamed devices created with -device > /default > /child[...] # created with qdev_create Yeah, this makes sense. By clocks, you mean things like rtc_clock, vm_clock, etc? Not the omap clocks which happen to live in /clocks in your series? Regards, Anthony Liguori > > Paolo > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 16:24 ` Anthony Liguori 0 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 16:24 UTC (permalink / raw) To: Paolo Bonzini Cc: Developers qemu-devel, Andreas Färber, KVM devel mailing list, quintela On 02/07/2012 09:21 AM, Paolo Bonzini wrote: > On 02/07/2012 03:56 PM, Anthony Liguori wrote: >>> Another related question is, should the 4th QOM series present a full >>> composition tree based on the legacy qdev bus concept? >> >> Composition, no. The legacy qbus concept doesn't model composition >> because it puts children created by composition (like the Cirrus VGA >> adapter) in the same context as a device created by a user (like an >> e1000 network card). >> >>> Currently it doesn't, but >>> if not, why not? That would help _a lot_ with removing PROP_PTR. >> >> One thing that we could do, is modify qdev_create() like: >> >> DeviceState *qdev_create_with_name(BusState *bus, const char *typename, >> const char *name) >> { >> // ... >> object_property_add_child(legacy_machine_root(), name, OBJECT(dev), &err); >> // assert if err due to conflicting property names >> } >> >> DeviceState *qdev_create(BusState *bus, const char *typename) >> { >> return qdev_create_with_name(bus, typename, typename); >> } >> >> Most devices only have a single instance. In the cases where there are >> multiple instances, we'll have to fix it up manually but that really >> shouldn't be all that hard. > > I'm wary of all plans that require to go through all the code once. What about > simply /devices/default/child[...] or something like that? The paths would be unstable, but maybe that's okay. I'd suggest doing child[rand()] to avoid the appearance that these paths are in any way shape or form stable. > BTW, I would like to change /i440fx to /devices/i440fx, so that we will have > clean namespaces: > > /block > ... > /chardev > ... > /clocks > ... > /devices > /peripheral > ... # named devices created with -device > /peripheral-anon > /child[...] # unnamed devices created with -device > /default > /child[...] # created with qdev_create Yeah, this makes sense. By clocks, you mean things like rtc_clock, vm_clock, etc? Not the omap clocks which happen to live in /clocks in your series? Regards, Anthony Liguori > > Paolo > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 16:24 ` Anthony Liguori @ 2012-02-07 16:27 ` Paolo Bonzini -1 siblings, 0 replies; 31+ messages in thread From: Paolo Bonzini @ 2012-02-07 16:27 UTC (permalink / raw) To: Anthony Liguori Cc: quintela, Andreas Färber, KVM devel mailing list, Developers qemu-devel On 02/07/2012 05:24 PM, Anthony Liguori wrote: >> I'm wary of all plans that require to go through all the code once. What about >> simply /devices/default/child[...] or something like that? > > The paths would be unstable, but maybe that's okay. I'd suggest > doing child[rand()] to avoid the appearance that these paths are in > any way shape or form stable. Sounds a bit inconvenient for humans (who in the end are those who debug things :)). >> BTW, I would like to change /i440fx to /devices/i440fx, so that we >> will have clean namespaces: >> >> /block >> /chardev >> /clocks >> /devices > > Yeah, this makes sense. By clocks, you mean things like rtc_clock, > vm_clock, etc? Not the omap clocks which happen to live in /clocks in > your series? No, I really meant the OMAP clocks. :) Basically if you have an abstract subclass TYPE_FOOS of TYPE_OBJECT, its instances would reside under /foos or something easily related to "foos". Paolo ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 16:27 ` Paolo Bonzini 0 siblings, 0 replies; 31+ messages in thread From: Paolo Bonzini @ 2012-02-07 16:27 UTC (permalink / raw) To: Anthony Liguori Cc: Developers qemu-devel, Andreas Färber, KVM devel mailing list, quintela On 02/07/2012 05:24 PM, Anthony Liguori wrote: >> I'm wary of all plans that require to go through all the code once. What about >> simply /devices/default/child[...] or something like that? > > The paths would be unstable, but maybe that's okay. I'd suggest > doing child[rand()] to avoid the appearance that these paths are in > any way shape or form stable. Sounds a bit inconvenient for humans (who in the end are those who debug things :)). >> BTW, I would like to change /i440fx to /devices/i440fx, so that we >> will have clean namespaces: >> >> /block >> /chardev >> /clocks >> /devices > > Yeah, this makes sense. By clocks, you mean things like rtc_clock, > vm_clock, etc? Not the omap clocks which happen to live in /clocks in > your series? No, I really meant the OMAP clocks. :) Basically if you have an abstract subclass TYPE_FOOS of TYPE_OBJECT, its instances would reside under /foos or something easily related to "foos". Paolo ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 16:27 ` Paolo Bonzini @ 2012-02-07 16:33 ` Anthony Liguori -1 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 16:33 UTC (permalink / raw) To: Paolo Bonzini Cc: Developers qemu-devel, Andreas Färber, KVM devel mailing list, quintela On 02/07/2012 10:27 AM, Paolo Bonzini wrote: > On 02/07/2012 05:24 PM, Anthony Liguori wrote: >>> I'm wary of all plans that require to go through all the code once. What about >>> simply /devices/default/child[...] or something like that? >> >> The paths would be unstable, but maybe that's okay. I'd suggest >> doing child[rand()] to avoid the appearance that these paths are in >> any way shape or form stable. > > Sounds a bit inconvenient for humans (who in the end are those who debug things > :)). There are tons of human readable paths to a single object so I don't think it's a problem. But no big deal with way since /devices/default should go away anyway. > >>> BTW, I would like to change /i440fx to /devices/i440fx, so that we >>> will have clean namespaces: >>> >>> /block >>> /chardev >>> /clocks >>> /devices >> >> Yeah, this makes sense. By clocks, you mean things like rtc_clock, >> vm_clock, etc? Not the omap clocks which happen to live in /clocks in >> your series? > > No, I really meant the OMAP clocks. :) Basically if you have an abstract > subclass TYPE_FOOS of TYPE_OBJECT, its instances would reside under /foos or > something easily related to "foos". Hrm, I don't like that very much. OMAP clocks are devices. Don't they belong in the devices hierarchy under the omap-clocks branch? The fact that they aren't DeviceState's is because DeviceState is a pile of cruft. Perhaps we should introduce a more streamlined Device base class and rename DeviceState to LegacyDevice or something like that. Regards, Anthony Liguori > > Paolo > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 16:33 ` Anthony Liguori 0 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 16:33 UTC (permalink / raw) To: Paolo Bonzini Cc: quintela, Developers qemu-devel, KVM devel mailing list, Andreas Färber On 02/07/2012 10:27 AM, Paolo Bonzini wrote: > On 02/07/2012 05:24 PM, Anthony Liguori wrote: >>> I'm wary of all plans that require to go through all the code once. What about >>> simply /devices/default/child[...] or something like that? >> >> The paths would be unstable, but maybe that's okay. I'd suggest >> doing child[rand()] to avoid the appearance that these paths are in >> any way shape or form stable. > > Sounds a bit inconvenient for humans (who in the end are those who debug things > :)). There are tons of human readable paths to a single object so I don't think it's a problem. But no big deal with way since /devices/default should go away anyway. > >>> BTW, I would like to change /i440fx to /devices/i440fx, so that we >>> will have clean namespaces: >>> >>> /block >>> /chardev >>> /clocks >>> /devices >> >> Yeah, this makes sense. By clocks, you mean things like rtc_clock, >> vm_clock, etc? Not the omap clocks which happen to live in /clocks in >> your series? > > No, I really meant the OMAP clocks. :) Basically if you have an abstract > subclass TYPE_FOOS of TYPE_OBJECT, its instances would reside under /foos or > something easily related to "foos". Hrm, I don't like that very much. OMAP clocks are devices. Don't they belong in the devices hierarchy under the omap-clocks branch? The fact that they aren't DeviceState's is because DeviceState is a pile of cruft. Perhaps we should introduce a more streamlined Device base class and rename DeviceState to LegacyDevice or something like that. Regards, Anthony Liguori > > Paolo > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 16:33 ` Anthony Liguori @ 2012-02-07 16:40 ` Peter Maydell -1 siblings, 0 replies; 31+ messages in thread From: Peter Maydell @ 2012-02-07 16:40 UTC (permalink / raw) To: Anthony Liguori Cc: Paolo Bonzini, quintela, Developers qemu-devel, KVM devel mailing list, Andreas Färber On 7 February 2012 16:33, Anthony Liguori <anthony@codemonkey.ws> wrote: > OMAP clocks are devices. Don't they belong in the devices hierarchy under > the omap-clocks branch? I think they should be interfaces, not devices. The device would be the PRCM (power, reset and clock manager) which provides a pile of registers for configuring the clocks and also outbound clock interfaces which you then wire up to the various devices like uart/usb/etc in the same way as you would IRQs or GPIO. -- PMM ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 16:40 ` Peter Maydell 0 siblings, 0 replies; 31+ messages in thread From: Peter Maydell @ 2012-02-07 16:40 UTC (permalink / raw) To: Anthony Liguori Cc: Paolo Bonzini, Andreas Färber, Developers qemu-devel, KVM devel mailing list, quintela On 7 February 2012 16:33, Anthony Liguori <anthony@codemonkey.ws> wrote: > OMAP clocks are devices. Don't they belong in the devices hierarchy under > the omap-clocks branch? I think they should be interfaces, not devices. The device would be the PRCM (power, reset and clock manager) which provides a pile of registers for configuring the clocks and also outbound clock interfaces which you then wire up to the various devices like uart/usb/etc in the same way as you would IRQs or GPIO. -- PMM ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 16:33 ` Anthony Liguori @ 2012-02-07 17:04 ` Paolo Bonzini -1 siblings, 0 replies; 31+ messages in thread From: Paolo Bonzini @ 2012-02-07 17:04 UTC (permalink / raw) To: Anthony Liguori Cc: Developers qemu-devel, Andreas Färber, KVM devel mailing list, quintela On 02/07/2012 05:33 PM, Anthony Liguori wrote: > Hrm, I don't like that very much. Yes, me neither actually. If the object representing the state of the OMAP board (struct omap_mpu_state_s) is QOMified, the clocks can easily get under it in the composition tree. Right now, that part is not even qdev. :) > OMAP clocks are devices. Don't they belong in the devices hierarchy > under the omap-clocks branch? If they were devices, yes. But they're not, and it wouldn't have been a great time investment to refactor them. :) Perhaps we can have /machine instead of /devices, a more generic name would do well. Then... > The fact that they aren't DeviceState's is because DeviceState is a pile > of cruft. Perhaps we should introduce a more streamlined Device base > class and rename DeviceState to LegacyDevice or something like that. ... light-weight components can inherit straight from Object and go under /machine. There would be /machine/clocks for example. Paolo ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 17:04 ` Paolo Bonzini 0 siblings, 0 replies; 31+ messages in thread From: Paolo Bonzini @ 2012-02-07 17:04 UTC (permalink / raw) To: Anthony Liguori Cc: quintela, Developers qemu-devel, KVM devel mailing list, Andreas Färber On 02/07/2012 05:33 PM, Anthony Liguori wrote: > Hrm, I don't like that very much. Yes, me neither actually. If the object representing the state of the OMAP board (struct omap_mpu_state_s) is QOMified, the clocks can easily get under it in the composition tree. Right now, that part is not even qdev. :) > OMAP clocks are devices. Don't they belong in the devices hierarchy > under the omap-clocks branch? If they were devices, yes. But they're not, and it wouldn't have been a great time investment to refactor them. :) Perhaps we can have /machine instead of /devices, a more generic name would do well. Then... > The fact that they aren't DeviceState's is because DeviceState is a pile > of cruft. Perhaps we should introduce a more streamlined Device base > class and rename DeviceState to LegacyDevice or something like that. ... light-weight components can inherit straight from Object and go under /machine. There would be /machine/clocks for example. Paolo ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 15:21 ` Paolo Bonzini @ 2012-02-07 16:41 ` Andreas Färber -1 siblings, 0 replies; 31+ messages in thread From: Andreas Färber @ 2012-02-07 16:41 UTC (permalink / raw) To: Paolo Bonzini Cc: Anthony Liguori, Developers qemu-devel, KVM devel mailing list, quintela Am 07.02.2012 16:21, schrieb Paolo Bonzini: > BTW, I would like to change /i440fx to /devices/i440fx, so that we will > have clean namespaces: > > /block > ... > /chardev > ... > /clocks > ... > /devices > /peripheral > ... # named devices created with -device > /peripheral-anon > /child[...] # unnamed devices created with -device > /default > /child[...] # created with qdev_create I don't like that, I prefer /i440fx over /devices/i440fx. I don't mind the other root-level nodes though. For PC-style machines I'd expect board-level stuff like the CPUs to appear directly under /. That would roughly correspond to the OpenFirmware device tree then. For embedded devices with SoCs I expect them to show up as child<>s of the SoC, but definitely not under some artificial /cpus. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 16:41 ` Andreas Färber 0 siblings, 0 replies; 31+ messages in thread From: Andreas Färber @ 2012-02-07 16:41 UTC (permalink / raw) To: Paolo Bonzini; +Cc: quintela, Developers qemu-devel, KVM devel mailing list Am 07.02.2012 16:21, schrieb Paolo Bonzini: > BTW, I would like to change /i440fx to /devices/i440fx, so that we will > have clean namespaces: > > /block > ... > /chardev > ... > /clocks > ... > /devices > /peripheral > ... # named devices created with -device > /peripheral-anon > /child[...] # unnamed devices created with -device > /default > /child[...] # created with qdev_create I don't like that, I prefer /i440fx over /devices/i440fx. I don't mind the other root-level nodes though. For PC-style machines I'd expect board-level stuff like the CPUs to appear directly under /. That would roughly correspond to the OpenFirmware device tree then. For embedded devices with SoCs I expect them to show up as child<>s of the SoC, but definitely not under some artificial /cpus. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 16:41 ` Andreas Färber @ 2012-02-07 16:53 ` Anthony Liguori -1 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 16:53 UTC (permalink / raw) To: Andreas Färber Cc: Paolo Bonzini, quintela, Developers qemu-devel, KVM devel mailing list On 02/07/2012 10:41 AM, Andreas Färber wrote: > Am 07.02.2012 16:21, schrieb Paolo Bonzini: >> BTW, I would like to change /i440fx to /devices/i440fx, so that we will >> have clean namespaces: >> >> /block >> ... >> /chardev >> ... >> /clocks >> ... >> /devices >> /peripheral >> ... # named devices created with -device >> /peripheral-anon >> /child[...] # unnamed devices created with -device >> /default >> /child[...] # created with qdev_create > > I don't like that, I prefer /i440fx over /devices/i440fx. I don't mind > the other root-level nodes though. Let's try Paolo's cleanup for now. I am worried about proliferation of things in the root hierarchy and the nice advantage of having /devices is that we can work towards making our build infrastructure roughly match our hierarchy. Since 1.1 is unstable for QOM, we can always change it later. > > For PC-style machines I'd expect board-level stuff like the CPUs to > appear directly under /. That would roughly correspond to the > OpenFirmware device tree then. I think devices trees are a bad example that should not be emulated. Regards, Anthony Liguori ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 16:53 ` Anthony Liguori 0 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 16:53 UTC (permalink / raw) To: Andreas Färber Cc: Paolo Bonzini, Developers qemu-devel, KVM devel mailing list, quintela On 02/07/2012 10:41 AM, Andreas Färber wrote: > Am 07.02.2012 16:21, schrieb Paolo Bonzini: >> BTW, I would like to change /i440fx to /devices/i440fx, so that we will >> have clean namespaces: >> >> /block >> ... >> /chardev >> ... >> /clocks >> ... >> /devices >> /peripheral >> ... # named devices created with -device >> /peripheral-anon >> /child[...] # unnamed devices created with -device >> /default >> /child[...] # created with qdev_create > > I don't like that, I prefer /i440fx over /devices/i440fx. I don't mind > the other root-level nodes though. Let's try Paolo's cleanup for now. I am worried about proliferation of things in the root hierarchy and the nice advantage of having /devices is that we can work towards making our build infrastructure roughly match our hierarchy. Since 1.1 is unstable for QOM, we can always change it later. > > For PC-style machines I'd expect board-level stuff like the CPUs to > appear directly under /. That would roughly correspond to the > OpenFirmware device tree then. I think devices trees are a bad example that should not be emulated. Regards, Anthony Liguori ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 13:45 ` Andreas Färber @ 2012-02-07 18:01 ` Anthony Liguori -1 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 18:01 UTC (permalink / raw) To: Andreas Färber Cc: quintela, Developers qemu-devel, KVM devel mailing list On 02/07/2012 07:45 AM, Andreas Färber wrote: > Am 06.02.2012 20:25, schrieb Juan Quintela: >> Please send in any agenda items you are interested in covering. > > I had some follow-up questions to the last call that remained > unanswered. We don't really need a call for that though, email is fine. > > http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html > > How is the realize step (DeviceState::init) supposed to translate to > Object-derived classes (e.g., CPU) and where to draw the line between > initfn and realize. Realize probably should be folded into Object or some intermediate object. The idea is that there will be a realized boolean property. When the level changes, it will invoke a realize() or unrealize() method depending on the direction. DeviceState will implement realize() and invoke init(). For unrealize(), it will invoke exit(). > For virtual methods Anthony outlined the intended scheme here: > http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00622.html > (Derived classes should save the parent's function pointer in their own > Class and initialize it from the parent class' function pointer.) > > Another topic that can be answered by email is what the time planning > for the 4th QOM series looks like. Are there things that developers of > new devices should keep in mind / start doing differently wrt SysBus? I think I answered this elsewhere. Regards, ANthony Liguori > Andreas > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 18:01 ` Anthony Liguori 0 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 18:01 UTC (permalink / raw) To: Andreas Färber Cc: Developers qemu-devel, KVM devel mailing list, quintela On 02/07/2012 07:45 AM, Andreas Färber wrote: > Am 06.02.2012 20:25, schrieb Juan Quintela: >> Please send in any agenda items you are interested in covering. > > I had some follow-up questions to the last call that remained > unanswered. We don't really need a call for that though, email is fine. > > http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html > > How is the realize step (DeviceState::init) supposed to translate to > Object-derived classes (e.g., CPU) and where to draw the line between > initfn and realize. Realize probably should be folded into Object or some intermediate object. The idea is that there will be a realized boolean property. When the level changes, it will invoke a realize() or unrealize() method depending on the direction. DeviceState will implement realize() and invoke init(). For unrealize(), it will invoke exit(). > For virtual methods Anthony outlined the intended scheme here: > http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg00622.html > (Derived classes should save the parent's function pointer in their own > Class and initialize it from the parent class' function pointer.) > > Another topic that can be answered by email is what the time planning > for the 4th QOM series looks like. Are there things that developers of > new devices should keep in mind / start doing differently wrt SysBus? I think I answered this elsewhere. Regards, ANthony Liguori > Andreas > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 18:01 ` Anthony Liguori @ 2012-02-07 18:17 ` Andreas Färber -1 siblings, 0 replies; 31+ messages in thread From: Andreas Färber @ 2012-02-07 18:17 UTC (permalink / raw) To: Anthony Liguori; +Cc: quintela, Developers qemu-devel, KVM devel mailing list Am 07.02.2012 19:01, schrieb Anthony Liguori: > On 02/07/2012 07:45 AM, Andreas Färber wrote: >> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html >> >> How is the realize step (DeviceState::init) supposed to translate to >> Object-derived classes (e.g., CPU) and where to draw the line between >> initfn and realize. > > Realize probably should be folded into Object or some intermediate object. > > The idea is that there will be a realized boolean property. When the > level changes, it will invoke a realize() or unrealize() method > depending on the direction. DeviceState will implement realize() and > invoke init(). For unrealize(), it will invoke exit(). That's fine. Question is, who is in charge of setting the realized property and some rules of what do we put in initfn and what in realize. Take the CPU, should CPU reset be done in realize or initfn? realize might overwrite values set by the user after initfn but would provide us with a reproducible state wrt reboot. Starting the VCPU thread would definitely be for realize, but currently this is all done from cpu_*_init() and having sequential calls to initfn and realize doesn't offer any advantage over doing it all in initfn. So given we do the split, who knows about these objects to call their realize function? Will there be some global QOM logic that calls realize on all objects instantiated so far (any ordering constraints then?) or is everyone themselves responsible for making this work, i.e. must I keep a global list of all CPUs initfn'ed to have their realize method called later? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 18:17 ` Andreas Färber 0 siblings, 0 replies; 31+ messages in thread From: Andreas Färber @ 2012-02-07 18:17 UTC (permalink / raw) To: Anthony Liguori; +Cc: Developers qemu-devel, KVM devel mailing list, quintela Am 07.02.2012 19:01, schrieb Anthony Liguori: > On 02/07/2012 07:45 AM, Andreas Färber wrote: >> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html >> >> How is the realize step (DeviceState::init) supposed to translate to >> Object-derived classes (e.g., CPU) and where to draw the line between >> initfn and realize. > > Realize probably should be folded into Object or some intermediate object. > > The idea is that there will be a realized boolean property. When the > level changes, it will invoke a realize() or unrealize() method > depending on the direction. DeviceState will implement realize() and > invoke init(). For unrealize(), it will invoke exit(). That's fine. Question is, who is in charge of setting the realized property and some rules of what do we put in initfn and what in realize. Take the CPU, should CPU reset be done in realize or initfn? realize might overwrite values set by the user after initfn but would provide us with a reproducible state wrt reboot. Starting the VCPU thread would definitely be for realize, but currently this is all done from cpu_*_init() and having sequential calls to initfn and realize doesn't offer any advantage over doing it all in initfn. So given we do the split, who knows about these objects to call their realize function? Will there be some global QOM logic that calls realize on all objects instantiated so far (any ordering constraints then?) or is everyone themselves responsible for making this work, i.e. must I keep a global list of all CPUs initfn'ed to have their realize method called later? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 2012-02-07 18:17 ` Andreas Färber (?) @ 2012-02-07 19:06 ` Anthony Liguori -1 siblings, 0 replies; 31+ messages in thread From: Anthony Liguori @ 2012-02-07 19:06 UTC (permalink / raw) To: Andreas Färber Cc: Developers qemu-devel, KVM devel mailing list, quintela On 02/07/2012 12:17 PM, Andreas Färber wrote: > Am 07.02.2012 19:01, schrieb Anthony Liguori: >> On 02/07/2012 07:45 AM, Andreas Färber wrote: >>> http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg04065.html >>> >>> How is the realize step (DeviceState::init) supposed to translate to >>> Object-derived classes (e.g., CPU) and where to draw the line between >>> initfn and realize. >> >> Realize probably should be folded into Object or some intermediate object. >> >> The idea is that there will be a realized boolean property. When the >> level changes, it will invoke a realize() or unrealize() method >> depending on the direction. DeviceState will implement realize() and >> invoke init(). For unrealize(), it will invoke exit(). > > That's fine. Question is, who is in charge of setting the realized > property Ideally, the user, but there is a lot of refactoring to get there. Realize should propagate through the composition tree (in such a way that it can be overridden, of course). > and some rules of what do we put in initfn and what in realize. instance_init: - initialize fields that don't depend on properties - install properties - initialize children realize: - validate all properties have sane values - perform initialization that depends on properties - take any actions that would logically "start" the device - propagate to children unrealize: - take any actions that would logically "stop" the device - propagate to children - restore fields to the values after reset finalize: - take any actions that would logically "stop" the device - free any sources of the device What we think of reset today is unrealize(). What with thing of as qdev_init is instance_init + realize. One thing I'd like to do is make the default implementation of unrealize() essentially be finalize + reinit in the same memory location. This would make it so that the vast majority of devices would not need to implement reset. > Take the CPU, should CPU reset be done in realize or initfn? Forget about reset as you know it. initfn should initialize state. Realize should only deal with starting the VM. > realize > might overwrite values set by the user after initfn but would provide us > with a reproducible state wrt reboot. > > Starting the VCPU thread would definitely be for realize, but currently > this is all done from cpu_*_init() and having sequential calls to initfn > and realize doesn't offer any advantage over doing it all in initfn. In general, if something can be done in initfn, it should be done there. > So given we do the split, who knows about these objects to call their > realize function? '/' is an object (it's a container). It will have a realize property that it propagates to all of it's children. So a user simply has to set /.realize = true and that will realize the entire graph of objects. > Will there be some global QOM logic that calls realize > on all objects instantiated so far (any ordering constraints then?) or > is everyone themselves responsible for making this work, i.e. must I > keep a global list of all CPUs initfn'ed to have their realize method > called later? Nope, it all will just magically work. Regards, Anthony Liguori > > Andreas > ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: KVM call agenda for Tuesday 7 2012-02-06 19:25 ` [Qemu-devel] " Juan Quintela @ 2012-02-07 14:23 ` Juan Quintela -1 siblings, 0 replies; 31+ messages in thread From: Juan Quintela @ 2012-02-07 14:23 UTC (permalink / raw) To: KVM devel mailing list; +Cc: Developers qemu-devel Juan Quintela <quintela@redhat.com> wrote: > Hi > > Please send in any agenda items you are interested in covering. As there were only one topic for the call, and Andreas suggested to use email, we cancel this week call. Have a nice day, Juan. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Qemu-devel] KVM call agenda for Tuesday 7 @ 2012-02-07 14:23 ` Juan Quintela 0 siblings, 0 replies; 31+ messages in thread From: Juan Quintela @ 2012-02-07 14:23 UTC (permalink / raw) To: KVM devel mailing list; +Cc: Developers qemu-devel Juan Quintela <quintela@redhat.com> wrote: > Hi > > Please send in any agenda items you are interested in covering. As there were only one topic for the call, and Andreas suggested to use email, we cancel this week call. Have a nice day, Juan. ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2012-02-07 19:06 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-02-06 19:25 KVM call agenda for Tuesday 7 Juan Quintela 2012-02-06 19:25 ` [Qemu-devel] " Juan Quintela 2012-02-07 13:45 ` Andreas Färber 2012-02-07 13:45 ` Andreas Färber 2012-02-07 13:52 ` Paolo Bonzini 2012-02-07 13:52 ` Paolo Bonzini 2012-02-07 14:56 ` Anthony Liguori 2012-02-07 14:56 ` Anthony Liguori 2012-02-07 15:21 ` Paolo Bonzini 2012-02-07 15:21 ` Paolo Bonzini 2012-02-07 16:24 ` Anthony Liguori 2012-02-07 16:24 ` Anthony Liguori 2012-02-07 16:27 ` Paolo Bonzini 2012-02-07 16:27 ` Paolo Bonzini 2012-02-07 16:33 ` Anthony Liguori 2012-02-07 16:33 ` Anthony Liguori 2012-02-07 16:40 ` Peter Maydell 2012-02-07 16:40 ` Peter Maydell 2012-02-07 17:04 ` Paolo Bonzini 2012-02-07 17:04 ` Paolo Bonzini 2012-02-07 16:41 ` Andreas Färber 2012-02-07 16:41 ` Andreas Färber 2012-02-07 16:53 ` Anthony Liguori 2012-02-07 16:53 ` Anthony Liguori 2012-02-07 18:01 ` Anthony Liguori 2012-02-07 18:01 ` Anthony Liguori 2012-02-07 18:17 ` Andreas Färber 2012-02-07 18:17 ` Andreas Färber 2012-02-07 19:06 ` Anthony Liguori 2012-02-07 14:23 ` Juan Quintela 2012-02-07 14:23 ` [Qemu-devel] " Juan Quintela
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.