Re: [PATCH] 9pfs: move qemu_dirent_dup() from osdep -> 9p-util

[Christian Schoenebeck]

On Dienstag, 1. März 2022 22:59:43 CET Peter Maydell wrote:
> On Tue, 1 Mar 2022 at 20:47, Christian Schoenebeck
> 
> <qemu_oss@crudebyte.com> wrote:
> > Function qemu_dirent_dup() is currently only used by 9pfs server, so move
> > it from project global header osdep.h to 9pfs specific header 9p-util.h.
> > 
> > Link:
> > https://lore.kernel.org/qemu-devel/CAFEAcA_=HAUNomKD2wurSVaAHa5mrk22A1oHK
> > LWUDjk7v6Khmg@mail.gmail.com/ Based-on:
> > <20220227223522.91937-12-wwcohen@gmail.com>
> > Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > ---
> > 
> >  hw/9pfs/9p-util.h    | 30 ++++++++++++++++++++++++++++++
> >  include/qemu/osdep.h | 13 -------------
> >  util/osdep.c         | 21 ---------------------
> >  3 files changed, 30 insertions(+), 34 deletions(-)
> > 
> > diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
> > index 1f74d37558..8b92614e6c 100644
> > --- a/hw/9pfs/9p-util.h
> > +++ b/hw/9pfs/9p-util.h
> > @@ -112,6 +112,36 @@ static inline off_t qemu_dirent_off(struct dirent
> > *dent)> 
> >  #endif
> >  }
> > 
> > +/**
> > + * 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()
> > + */
> 
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
> 
> since it's just code movement, but those "@c"s look a bit weird:
> are they really valid kerneldoc comment markup?
> 
> thanks
> -- PMM

You are right, that's Doxygen format, not kerneldoc format.

If you don't mind I send a separate, subsequent patch that just wipes the 
"@c"s away, and leave this patch as-is (as this one is pure refactoring).

Alternatively I could replace the "@c"s by kerneldoc's solution which 
apparently is "::foo" I think ("foo" being the inlined C code).

Best regards,
Christian Schoenebeck