Hi, On 28.01.2018 10:02, Pavel Pisa wrote: > Hello Paolo, > > On Friday 26 of January 2018 12:12:32 Paolo Bonzini wrote: >> Coincidentially, I have some time on a flight next Monday. :) I >> obviously cannot really _test_ anything, but I can at least do the >> changes below and set up all the QOM boilerplate. > > thanks much for offer to help. > > Deniz Eren or Oleksij Rempel can test your changes as well.
just tell me wen and what should i test :) > I have prepared branch "can-pci-qom" in GitLab repository > > https://gitlab.fel.cvut.cz/canbus/qemu-canbus > > https://gitlab.fel.cvut.cz/canbus/qemu-canbus/tree/can-pci-qom > > and I have updated all PCI devices to use realize() instead of init(), > eliminated all uses of exit() and changed error reporting to use > error_setg() and error_setg_errno(). So I think that there is > no fatal blocker in these files. Problematic is setup > of connect_to_host variant > > can_bus_set_connect_to_host(can_bus_connect_to_host_socketcan); > > in "hw/can/can_socketcan.c" and location of this file > in HW. I keep it there to have all CAN support *.c > files in single place for now. > > I have studied "tests/check-qom-proplist.c" for while > but I expect that you will be much more successfull > and efficient to define mainline acceptable object model. > > Thanks again, > > Pavel > >>>> The best way would be a QOM object. That is, you would do >>>> >>>> -object can-bus,id=canbus0 >>>> -object can-host-socketcan,id=can0-host,canbus=canbus0,if=can0 >>>> -device kvaser_pci,canbus=canbus0 >>> >>> I would prefer to allow CAN emulation to be used without >>> explicit can-bus object creation specified on the command line. >>> The bus object could be created when requested by >>> can-host-socketcan or device (kvaser_pci) automatically. >> >> It could be fine to allow "-device kvaser_pci" to automatically create a >> private bus. However, IMO it's better to be explicit in the case where >> multiple objects (e.g. can-host-socketcan and the kvaser_pci device, or >> two controllers) want to connect to the same object. >> >>>> Separating the QOM objects is a bit more work, but it makes the >>>> semantics clearer. The classes would be: >>>> >>>> - can-bus and an abstract class can-host, which would inherit directly >>>> from TYPE_OBJECT and implement TYPE_USER_CREATABLE >>>> >>>> - can-host-socketcan, which would inherit from can-host (and take the >>>> TYPE_USER_CREATABLE implementation from there) >>>> >>>> while CanBusClientState and CanBusClientInfo need not be QOMified. >>> >>> May it be, can-host-socketcan can be based directly on TYPE_OBJECT, >>> because only QEMU CAN bus specific part is CanBusClientState which >>> allows it to connect to the CAN bus same way as other CAN controllers >>> connect to the bus. >> >> The abstract class "can-host" is useful to keep can-host-socketcan free >> of things that are not specific to SocketCAN, but it's just a small detail. > >
