|
[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).
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |