Re: [PATCH 34/43] audio: rename AudioState -> AudioBE

[BALATON Zoltan <balaton@eik.bme.hu>]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

On Tue, 21 Oct 2025, Marc-André Lureau wrote:
> Hi
>
> On Tue, Oct 21, 2025 at 1:42 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> On 10/21/25 11:30, Paolo Bonzini wrote:
>>> On 10/21/25 11:03, marcandre.lureau@redhat.com wrote:
>>>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>>>>
>>>> Naming is hard. But in general in QEMU, a host "backend" is the term
>>>> used to fullfill the request made by the device "frontend".
>>>>
>>>> Note that "audiodev" is the corresponding QAPI type name (or
>>>> configuration).
>>>
>>> BE and FE aren't used in existing code though.  Looking at current use:
>
> There is a top-level backends/ though. I meant to say that it's
> usually clearer for everyone when we talk about "backend" vs
> "frontend" (or not?), and I wish we would follow that naming more in
> the code.
>
>>>
>>> - BlockDriverState*/BlockBackend*
>>>
>
> I am not very familiar with the block subsystem, but it is seems
> BlockBackend is actually the backend and BlockDriverState is
> implementation data detail. Correct me if I'm wrong
>
>>> - Chardev*/CharBackend
>>>
>
> Those are actually always confusing... and I remember I attempted to
> rename it in the past... CharBackend is the front-end side..
>
>>> - NetClientState*/NICState*
>>>
>>> ... it's actually quite common for the *frontend* to have a pointer or
>>> object of type FooBackend; that would give Audiodev* and AudioBackend*.
>>
>> Hmm, I have to correct myself.
>>
>> QEMUSoundCard's name field is basically unused, and QEMUSoundCard should
>> be just an Audiodev*.  There's no need for a separate AudioFE struct.
>>
>
> For audio, it's pretty obvious that we have "backend" object to
> implement the host audio subsystem details, while "QEMUSoundCard" is
> the "frontend", or "client/user" context.
>
> Imho, it's clearer to see the relation between the two objects if we
> name them "backend" and "frontend" accordingly. If the "AudioBE" &
> "AudioFE" short versions aren't readable enough, I am fine naming
> "AudioBackend" & "AudioFrontend"

AudioBE is confusing as BE often stands for big endian and no example of 
using it for Backend. Thus AudioBackend while longer is clearer so gets my 
vote too (or anthing else less confusing than AudioBE).

Regards,
BALATON Zoltan