On Tue, 22 Feb 2022 14:54:17 +0100 Christian Schoenebeck <qemu_...@crudebyte.com> wrote:
> On Dienstag, 22. Februar 2022 14:21:52 CET Peter Maydell wrote: > > On Thu, 17 Feb 2022 at 16:43, Christian Schoenebeck > > > > <qemu_...@crudebyte.com> wrote: > > > diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h > > > index d1660d67fa..ce12f64853 100644 > > > --- a/include/qemu/osdep.h > > > +++ b/include/qemu/osdep.h > > > @@ -805,6 +805,19 @@ static inline int > > > platform_does_not_support_system(const char *command)> > > > } > > > #endif /* !HAVE_SYSTEM_FUNCTION */ > > > > > > +/** > > > + * Duplicate directory entry @dent. > > > + * > > > + * It is highly recommended to use this function instead of open coding > > > + * duplication of @c dirent objects, because the actual @c struct @c > > > dirent + * size may be bigger or shorter than @c sizeof(struct dirent) > > > and correct + * handling is platform specific (see gitlab issue #841). > > > + * > > > + * @dent - original directory entry to be duplicated > > > + * @returns duplicated directory entry which should be freed with > > > g_free() > > > + */ > > > +struct dirent *qemu_dirent_dup(struct dirent *dent); > > > > Hi; I just noticed this has landed in git recently. > > Please don't add new prototypes to osdep.h -- it is > > a header included by every single C file in the tree, so > > making it bigger slows down compilation. osdep.h is supposed > > to contain only: > > * things which everybody needs > > * things without which code would work on most platforms but > > fail to compile or misbehave on a minority of host OSes > > (ie system incompatibility handling) > > > > This prototype is neither of those -- please find or create a more > > appropriate header file for it, that can be included only by the > > source files that actually need it. > > > > thanks > > -- PMM > > Good to know, because the pending Darwin series would have added stuff to > osdep.h as well: > https://lore.kernel.org/qemu-devel/20220220165056.72289-10-wwco...@gmail.com/ > > We'll find a different place. > I suggest you move all that under hw/9pfs for now since it is the only user and we don't really know if there will ever be a new one (especially now that development on C virtiofsd is slowing down). Cheers, -- Greg > Thanks! > > Best regards, > Christian Schoenebeck > >
