On Thu, 28 Jan 2021 at 22:00, Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Thu, Jan 28, 2021 at 09:20:31PM +0530, Shreyansh Chouhan wrote:
> > (Gerd, I wasn't able to get gmail to quote your email, so I have just
> copy
> > pasted the relavant parts.)
> >
> > > Yes.  net_conf is common config (backend, mac address, maybe more) for
> > > network devices.  For sound devices that would audiodev (link the
> device
> > > to a backend which then handles alsa/pulse/jack/oss/sdl/whatever).
> >
> > Ah I see, so the net_conf corresponds to audiodev?
>
> Oops.  Confused that.  nic_conf (struct NICConf) is the common config
> for all network devices, not net_conf.
>
> See DEFINE_NIC_PROPERTIES() in include/net/net.h
>
> NICConf.peers (exposed as "netdev" property) links the emulated device
> (frontend) to a netdev (backend) which actually processes the packets
> sent by the guest.
>
> In a simliar way the audiodev property links the emulated audio device
> to a backend which handles the host-side audio playback using alsa,
> pulseaudio or something else.
>
> > I thought it would correspond to `virtio_snd_conf`. So as alex said,
> > `virtio_snd_conf` is the front end configuration.
>
> Correct.
>
> The backend is configured separately, i.e.
>
>   -netdev user,id=net0,$moreargs
>
> or
>
>   -audiodev alsa,id=snd0,$moreargs
>
> Then the two are linked by id, i.e.
>
>   -device virtio-net-pci,netdev=net0
>
> or
>
>   -device virtio-sound-pci,audiodev=snd0
>

Ah ha! So `virtio-snd-conf` corresponds to the `-device` configuration
and `audiodev` to the backend configuration. I think the audio code
now makes more sense to me. I will give it another read.

> > The only thing really required is the audiodev property.  Everything
> > > else can be hard-coded initially, and once the basics are working
> > > refined (like adding properties for jack labels, ...).
> >
> > So in the realize function I set up the audiodev, right? Also in that
> case
> > why the difference between the net and sound devices? In the net
> > device we set up the common config in net_conf. Does the net_conf
> > somehow later sets up NetDev too?
> >
> > And what is a NetClientState? Is the NetClient the emulated guest? This
> > confuses me a lot. I can't understand what will be the parellel audio
> device
> > property.
>
> Not fully sure what NetClientState is, I guess it is shared struct for
> both frontend and backend to manage the connection state.
>
> The audio subsystem has simliar structs, SWVoiceIn and SWVoiceOut for
> example.  There also is QEMUSoundCard.  I'd suggest to check out the
> source code of other audio devices for code examples.
>
I will read it and revert back if I have any queries.

>
> > Also I can't seem to find where we parse the command line options
> > passed to qemu.  The code structure is a bit different from what I had
> > expected. In virtio_net_device_realize we set duplex to half or full
> > depending on the value of the net_conf.duplex_str. But I couldn't find
> > where we actually set it.
>
> See virtio_net_properties[].  There is a line in the array:
>
>     DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
>
I thought this just declared a property, and didn't set it. But now that in
retrospect
we already declared the variable when we defined the struct so that doesn't
make
sense.

>
> And the whole array is registered using:
>
>    device_class_set_props(dc, virtio_net_properties);
>
> That is enough to make those properties work, the qemu core handles
> everything for you.  See hw/core/qdev-properties.c if you are curious,
> but you can also just consider that a black box at service for you ;)
>
I think I will give it a quick look :P

>
> take care,
>   Gerd
>
> Thanks a lot!
--
Shreyansh