On Thu, 28 Jan 2021 at 22:00, Gerd Hoffmann <kra...@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
