[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 04/15] Break virNetServer into virNetSubServers



On Fri, Apr 17, 2015 at 11:22:32AM +0100, Daniel P. Berrange wrote:
On Thu, Apr 16, 2015 at 04:46:39PM +0200, Martin Kletzander wrote:
Each subserver has its own RPC programs, services, workers, keepalive,
clients etc.  Hence (possible) multiple subservers are properly
separated.

The part in remote.c is just mechanical, the same applies to most of the
code movement from virnetserver.c to virnetsubserver.c.

So, the problem we're facing here is that virNetServer is really filling
two distinct roles in one class - it is the thing that manages the overall
daemon process state, as well as managing the server connection/services.

So the splitting up you're doing does rather make sense. I wonder if we
could name it differently though. eg have virNetDaemon to handle the
process level stuff, and virNetServer to handle the network level stuff.
So what is in virnetserver.c moves to virnetdaemon.c and your new
virnetsubserver.c becomes the new virnetserver.c


Your naming makes more sense to me, I'll switch to that.

[...]
@@ -76,10 +81,12 @@ int virNetServerAddSignalHandler(virNetServerPtr srv,
                                  void *opaque);

 int virNetServerAddService(virNetServerPtr srv,
+                           int subServerID,
                            virNetServerServicePtr svc,
                            const char *mdnsEntryName);

 int virNetServerAddProgram(virNetServerPtr srv,
+                           int subServerID,
                            virNetServerProgramPtr prog);

How about just moving these two methods to take the virNetSubServerPtr as
their first arg, instead of needing to pass virNetServer + subServerID ?
Not a big deal either way though.


Because that was a really old and stupid idea :D  Not dealing with the
ID is better and more readable.  I wanted to have better identifier
than integer, but I don't know whether using string would be worth it.

Attachment: signature.asc
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]