Re: [Qemu-devel] Help on effort estimation

[Blue Swirl <blauwirbel@gmail.com>]

On 3/14/09, Patrizio Boschi <patrizio.boschi@gmail.com> wrote:
> Hi, I'm doing some academical research about the development of device
>  emulators. So far I managed to create an emulator of a simple PCI
>  device (Intel i6300ESB watchdog timer) just to get an idea of the
>  development process in QEMU, and studied some of the other emulators
>  in qemu/hw. I was also looking for some basic metrics (e.g. sloc,
>  emulator sloc/driver sloc, function points) and models (e.g. cocomo
>  II) to do some effort estimation (e.g. how many person-month to
>  emulate a particular device model?).
>
>  At this point, a little help from you would really benefit my studies
>  and research. So... the questions are very simple :)
>  - does someone have old or future development schedules for some of
>  the qemu modules to share?

You could look at the SVN log of some x86 devices and make the
assumption that they are fully implemented now.

>  - could someone (roughly) estimate the work-days needed to develop the
>  emulator of a very simplce device (e.g. an hardware timer), an hard
>  one (e.g. a VMEbus bridge with poor documentation), a mid one (e.g. an
>  ethernet card), given an experienced programmer?

I think the time needed depends more on whether similar devices exist
or if you have to create a completely new class of device from
scratch. It's possible to develop a working device in a day or two.
Finding out all obscure corner cases may take much longer time, but
usually when a bug or deviation is discovered, fixing it is easy.

>  - could someone (roughly)  estimate which are the prerequisites to
>  successfully develop a particular device emulator? (e.g. datasheet,
>  real hardware, driver source code, vendor help, luck, girls, ...)

A good, accurate datasheet (or if there is an electrical datasheet and
a user's manual, the latter) is number one. It's possible to develop
an emulator using driver source code, but that may not handle all
cases (those that drivers in another OS may use). The driver may
describe workarounds for device errata which may have been unknown
when the datasheet was published.