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

Re: [Xen-devel] [PATCH v6 1/6] libxl: add infrastructure to track and query 'recent' domids

Durrant, Paul writes ("RE: [PATCH v6 1/6] libxl: add infrastructure to track 
and query 'recent' domids"):
> [Ian:]
> > IMO the reuse timeout call and the clock_gettime call should be put in
> > libxl__open_domid_history; and the time filtering check should be
> > folded into libxl__read_recent.
> Ok. I was having a hard time guessing just exactly what you're looking for. I 
> think that makes it a little clearer.
> > In my review of v4 I wrote:
> > 
> >   Do you think this can be combined somehow ?  Possibilities seem to
> >   include: explicit read_recent_{init,entry,finish} functions; a single
> >   function with a "per-entry" callback; same but with a macro.  If you
> >   do that you can also have it have handle the "file does not exist"
> >   special case.
> > 
> > You've provided the read_recent_entry function but the "init" function
> > libxl__open_domid_history does too little.  This series seems to be
> > moving towards what I called read_recent_{init,entry,finish} (which
> > should probably have the timestamp and FILE* in a struct together) but
> > it seems to be doing so quite slowly.
> Now again I'm not sure *exactly* what you want me to do, but I'll have 
> another guess.

Maybe it would be better for us to try to come to a shared
understanding before you do another respin...

> >  - It encourages vacuous log messages whose content is mainly in the
> >    function and line number framing:
> >        +    LOGE(ERROR, "failed");
> >        +    return ERROR_FAIL;
> >        +}
> >    rather than
> >        if (!*f) {
> >            LOGE(ERROR, "failed to open recent domid file `%s'", path);
> >            rc = ERROR_FAIL;
> >            goto out;
> >        }
> >    (and the latter is to be preferred).
> But by asking me to put the error handling inside the sub-functions I lost 
> context such as 'path' which was present in the previous structure. I could 
> pass in an argument purely for the benefit of a log function but that seems 
> excessive. I guess I will pull the error logging out again, but that seemed 
> to be against your requirement to de-duplicate code.

I think the path needs to be passed into these functions.  This is why
I think the functions need to take a struct* as an argument, for their
shared state (including the path and the other stuff).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.