Re: [PATCH 35/43] audio: rename QEMUSoundCard -> AudioFE

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Oct 21, 2025 at 05:06:01PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Oct 21, 2025 at 4:50 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> >
> > On Tue, 21 Oct 2025, Marc-André Lureau wrote:
> > > On Tue, Oct 21, 2025 at 4:13 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > >>
> > >> On Tue, 21 Oct 2025, marcandre.lureau@redhat.com wrote:
> > >>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > >>>
> > >>> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > >>> ---
> > >>> audio/audio.h                       | 20 ++++++++++----------
> > >>> audio/audio_int.h                   |  6 +++---
> > >>> audio/audio_template.h              |  4 ++--
> > >>> hw/audio/lm4549.h                   |  2 +-
> > >>> include/hw/audio/asc.h              |  2 +-
> > >>> include/hw/audio/virtio-snd.h       |  2 +-
> > >>> include/hw/display/xlnx_dp.h        |  2 +-
> > >>> include/hw/isa/vt82c686.h           |  2 +-
> > >>> include/hw/qdev-properties-system.h |  2 +-
> > >>> audio/audio.c                       | 10 +++++-----
> > >>> hw/audio/ac97.c                     |  6 +++---
> > >>> hw/audio/adlib.c                    |  6 +++---
> > >>> hw/audio/asc.c                      |  6 +++---
> > >>> hw/audio/cs4231a.c                  |  4 ++--
> > >>> hw/audio/es1370.c                   |  6 +++---
> > >>> hw/audio/gus.c                      |  6 +++---
> > >>> hw/audio/hda-codec.c                |  6 +++---
> > >>> hw/audio/lm4549.c                   |  2 +-
> > >>> hw/audio/pcspk.c                    |  4 ++--
> > >>> hw/audio/sb16.c                     |  4 ++--
> > >>> hw/audio/via-ac97.c                 |  4 ++--
> > >>> hw/audio/virtio-snd.c               |  4 ++--
> > >>> hw/audio/wm8750.c                   |  6 +++---
> > >>> hw/core/qdev-properties-system.c    |  4 ++--
> > >>> hw/display/xlnx_dp.c                |  2 +-
> > >>> hw/usb/dev-audio.c                  |  6 +++---
> > >>> 26 files changed, 64 insertions(+), 64 deletions(-)
> > >>>
> > >>> diff --git a/audio/audio.h b/audio/audio.h
> > >>> index 845e078169..a43ca0700c 100644
> > >>> --- a/audio/audio.h
> > >>> +++ b/audio/audio.h
> > >>> @@ -70,18 +70,18 @@ struct AudioBEClass {
> > >>> };
> > >>>
> > >>> typedef struct AudioBE AudioBE;
> > >>> -typedef struct QEMUSoundCard {
> > >>> +typedef struct AudioFE {
> > >>
> > >> You could also leave it as it is. While it's a bit odd naming it's clear
> > >> enough and not at least the local variables now called "card" match the
> > >> type which would not be the case if you rename it to Audiodev or something
> > >> else but not rename all the locals. So maybe it does not worth the churn
> > >> to change this type name.
> > >
> > > I think it's still worth it. Local variables are locals, and usually
> > > easy to understand by the context and using their types. It's easy to
> > > rename "card" to "audio_fe" or "frontend" though, I can do this in
> > > this change too.
> >
> > The point is to have less churn not more so renaming locals from card to
> > fe or something (but definitely not to a longer name than currently) would
> > just be more churn for not much more clarity. Therefore I argued that
> 
> Renaming is making churn, I agree. But if the end result allows more
> readable code, even slightly, we should consider it.
> 
> Imho AudioState and QEMUSoundCard are bad type names that don't help.
> I value type names a lot more than variable names, especially now that
> we have LSP, I am probably not the only one.
> 
> I proposed AudioBE and AudioFE, for simplicity consistency and to
> avoid some naming clashes with QAPI types.
> 
> Agree, BE and FE are not the most readable, so AudioBackend and
> AudioFrontend seems agreeable (local variables or in fn_name_for_be
> use usually a shorter version though).

I find both ChardevFrontend and AudioFrontend as somewhat confusing,
because the Device is frontend. IIUC ChardevFrontend/AudioFrontend
act more like a way to associate a frontend and backend together.
Can we call the objects something like a "Connection" / "Attachment"
/ "Link" ?


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|