On Mon, Aug 23, 2021 at 9:53 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Mon, Aug 23, 2021 at 9:11 AM houzj.f...@fujitsu.com > <houzj.f...@fujitsu.com> wrote: > > > 4) > > -extern File SharedFileSetCreate(SharedFileSet *fileset, const char *name); > > -extern File SharedFileSetOpen(SharedFileSet *fileset, const char *name, > > - int mode); > > -extern bool SharedFileSetDelete(SharedFileSet *fileset, const char *name, > > - bool > > error_on_failure); > > extern void SharedFileSetDeleteAll(SharedFileSet *fileset); > > -extern void SharedFileSetUnregister(SharedFileSet *input_fileset); > > > > I noticed the patch delete part of public api, is it better to keep the old > > api and > > let them invoke new api internally ? Having said that, I didn’t find any > > open source > > extension use these old api, so it might be fine to delete them. > > Right, those were internally used by buffile.c but now we have changed > buffile.c to directly use the fileset interfaces, so we better remove > them. >
I also don't see any reason to keep those exposed from sharedfileset.h. I see that even in the original commit dc6c4c9dc2, these APIs seem to be introduced to be used by buffile. Andres/Thomas, do let us know if you think otherwise? One more comment: I think v1-0001-Sharedfileset-refactoring doesn't have a way for cleaning up worker.c temporary files on error/exit. It is better to have that to make it an independent patch. -- With Regards, Amit Kapila.
