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 >
