> > > Yes, I think at least for the moment it should work fine this way. > > > Eventually, I'd like to integrate it with --export (and associated QMP > > > commands, which are still to be created), too. Maybe at that point we > > > want to make the QOM object not user creatable any more. > > > > Does it mean TYPE_USER_CREATABLE interface in QOM will become > > deprecated in the future? I'm curious what are the reasons for making > > QOM object no user creatable? Because we may still need to start > > vhost-user block device backend through HMP or QMP instead of stating > > it as a standalone-alone daemon.
> Not in general, but if we have something like a block-export-add QMP > command, the QOM interface would be redundant. We could still leave it > there and have both a low-level and a high-level interface, but whether > we would want to is something we still have to decide. I see. So QOM interface will still be used as a low-level interface. In the draft version, vhost-user-blk-server is started using specific command vhost_user_server_start/vhost_user_server_stop which proivide interfaces easier for implementing block-export-add QMP command. But in later versions, only object_add/object_del syntax is supported to start/stop vhost-user-blk-server. I'll keep an eye on how the storage daemon develops and adapt my code accordingly. On Sun, Feb 2, 2020 at 5:33 PM Kevin Wolf <kw...@redhat.com> wrote: > > Am 31.01.2020 um 17:42 hat Coiby Xu geschrieben: > > > Yes, I think at least for the moment it should work fine this way. > > > Eventually, I'd like to integrate it with --export (and associated QMP > > > commands, which are still to be created), too. Maybe at that point we > > > want to make the QOM object not user creatable any more. > > > > Does it mean TYPE_USER_CREATABLE interface in QOM will become > > deprecated in the future? I'm curious what are the reasons for making > > QOM object no user creatable? Because we may still need to start > > vhost-user block device backend through HMP or QMP instead of stating > > it as a standalone-alone daemon. > > Not in general, but if we have something like a block-export-add QMP > command, the QOM interface would be redundant. We could still leave it > there and have both a low-level and a high-level interface, but whether > we would want to is something we still have to decide. > > > > As for test cases, do you think it would be hard to just modify the > > > tests to send an explicit 'quit' command to the daemon? > > > > Accroding to > > https://patchew.org/QEMU/20191017130204.16131-1-kw...@redhat.com/20191017130204.16131-10-kw...@redhat.com/, > > > > > +static bool exit_requested = false; > > > + > > > +void qemu_system_killed(int signal, pid_t pid) > > > +{ > > > + exit_requested = true; > > > +} > > > > if exit_requested = true, qemu-storage-daemon will exit the main loop > > and then quit. So is calling qemu_system_killed by what you means "to > > send an explicit 'quit' command to the daemon"? > > qemu_system_killed() is call in the signal handlers for, amongst others, > SIGTERM and SIGINT. This is one way to stop the storage daemon (for > manual use, sending SIGINT with Ctrl-C is probably the easiest way). > > What I actually meant is the 'quit' QMP command which will cause > qmp_quit() to be run, which contains the same code. But if sending a > signal is more convenient, that's just as good. > > Kevin > > > On Fri, Jan 17, 2020 at 6:12 PM Kevin Wolf <kw...@redhat.com> wrote: > > > > > > Am 17.01.2020 um 09:12 hat Coiby Xu geschrieben: > > > > Excellent! I will add an option (or object property) for > > > > vhost-user-blk server oject which will tell the daemon process to exit > > > > when the client disconnects, thus "make check-qtest" will not get held > > > > by this daemon process. After that since Kevin's qemu-storage-daemon > > > > support "-object" option > > > > (https://patchew.org/QEMU/20191017130204.16131-1-kw...@redhat.com/20191017130204.16131-3-kw...@redhat.com/) > > > > and vhost-user-server is a user-creatable QOM object, it will work out > > > > of the box. > > > > > > Yes, I think at least for the moment it should work fine this way. > > > Eventually, I'd like to integrate it with --export (and associated QMP > > > commands, which are still to be created), too. Maybe at that point we > > > want to make the QOM object not user creatable any more. > > > > > > Would it make sense to prefix the object type name with "x-" so we can > > > later retire it from the external user interface without a deprecation > > > period? > > > > > > As for test cases, do you think it would be hard to just modify the > > > tests to send an explicit 'quit' command to the daemon? > > > > > > > I'm curious when will be formal version of qemu-storage-daemon > > > > finished so I can take advantage of it? Or should I apply the RFC > > > > PATCHes to my working branch directly and submit them together with > > > > the patches on vhost-user-blk server feature when posting v3? > > > > > > It's the next thing I'm planning to work on after completing the > > > coroutine-base QMP handlers (which I hope to get finished very soon). > > > > > > For the time being I would suggest that you put any patches that depend > > > on qemu-storage-daemon (if you do need it) at the end of your series so > > > that we could apply the first part even if the storage daemon isn't in > > > yet. > > > > > > The latest version of my patches is at: > > > > > > git://repo.or.cz/qemu/kevin.git storage-daemon > > > > > > But if you just need something for testing your code, I think it would > > > even make sense if you kept your standalone tool around (even though > > > we'll never merge it) and we'll deal with integration in the storage > > > daemon once both parts are ready. > > > > > > Kevin > > > > > > > > > -- > > Best regards, > > Coiby > > > -- Best regards, Coiby