Re: [Qemu-devel] [PATCH] Document Qemu coding style

[malc <av1474@comtv.ru>]

On Tue, 31 Mar 2009, David Turner wrote:

> On Tue, Mar 31, 2009 at 6:18 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> 
> >
> > True enough for the comments part. There are still some areas that I
> > don't understand well, for example TB handling and its inherent
> > limitations.
> >
> > Which part of the source you find subtle and magical but not commented
> > enough?
> >
> 
> ok, here are a few things that ring a bell, there are probably a lot others:
> 
> the software mmu implementation in system mode is *really* hard to
> understand at
> first. It took me a long time to grasp the various aspects of it, including
> these:
> 
>    - loads/stores in kernel or userspace map to different translated code
>    fragments
>    - loads/stores in different emulated CPUs also map to different
>    translated code.
>    - the way i/o memory access is controlled in fine details and relates to
>    the rest of the MMU.
> 
> most of what happens in exe.c is black-magic :-)
> 
> how the audio-subsystem works and its relationship with hardware
> emulation is subtle.  For my work on the Android emulator, I have
> modified three audio-backends and wrote one from scratch. It took me
> several tries to get things to an acceptable state. What I didn't
> understand first is that there is no common time-based used by all
> components involved.
> 

For starters you could have asked about things you believe are subtle.

Now to the part i do not understand: what do you mean by time-based(sic)?

There's one clock involved, as far as audio is concerned, and it's the
one dervied from the speed with which host audio can consume/produce
audio, anything else just doesn't work (for scenarios i was interested
in anyway)

As for the question of why everything just calls audio_pcm_sw_write
raised in AUDIO.txt, the reason, if my memory serves and it might as
well not do that all that well, things are the way they are for the
reason that any given driver can, theoretically, use the respective
audio subsystems/libraries own, less naive, st_rate_flow equivalent.

[..snip..]

> For the record, here are attached a few documents I wrote to detail
> what I've "discovered" until now. Hope some one can find them useful
> (Sorry if some of them are focused on ARM system emulation only).
> 
> Regards
> 

P.S. Last/only time i looked at Android couldn't help but notice that,
     apart from other things, capture was implemented for coreaudio,
     it would have been nice, if for nothing else but the sake of
     completeness, to have that in main QEMU too.

-- 
mailto:av1474@comtv.ru