All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratik Parvati <pratikp@vayavyalabs.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: qemu-devel@nongnu.org
Subject: Re: QEMU Library support
Date: Mon, 10 Aug 2020 19:01:15 +0530	[thread overview]
Message-ID: <CA+aXn+G4EWAoGqgEuDW9j5dQSNJX2g31aGt521YL3MV9eyPzVg@mail.gmail.com> (raw)
In-Reply-To: <87lfim3ipq.fsf@linaro.org>

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

Just to hide the core QEMU implementation from the device code. QEMU core
source code remains the same for all device; So, was thinking a way of
hiding it from the rest of the device code.

Regards,
Pratik


On Mon, Aug 10, 2020 at 3:50 PM Alex Bennée <alex.bennee@linaro.org> wrote:

>
> Pratik Parvati <pratikp@vayavyalabs.com> writes:
>
> > As an experiment, I have modelled non-existing ARM Watchdog model (SP805)
> > interfaced to the versatile PB platform. What actually I was looking is -
> > some sort of QEMU library, where I can model new device outside the QEMU
> > source hierarchy and still be able to compile it using QEMU library and
> > include files to add support for the new device. If QEMU doesn't provide
> a
> > library, Is there a flexibly that I can tweak something inside the QEMU
> to
> > generate it?
>
> Not really. While most devices are fairly standalone they can access all
> sorts of QEMU APIs. Why not just implement your device inside the QEMU
> source tree?
>
> >
> > Regards,
> > Pratik
> >
> >
> > On Mon, Aug 10, 2020 at 3:18 PM Alex Bennée <alex.bennee@linaro.org>
> wrote:
> >
> >>
> >> Pratik Parvati <pratikp@vayavyalabs.com> writes:
> >>
> >> > Hi team,
> >> >
> >> > Lately, I have been working on QEMU modeling and interfacing it into
> the
> >> > existing platform. What actually I wanted to check is; whether QEMU
> >> > supports library that gives developers a clean interface to develop
> and
> >> > integrate peripheral model in to QEMU. I know of the Greensocs SystemC
> >> > bridge - but that was quite difficult to work with in past.
> >>
> >> Not really - with a few exceptions like vhost-user and in KVM device
> >> emulation all devices are emulated in the QEMU code base. As a result
> >> the best way to maintain a device is to have it integrated upstream
> >> (along with some tests to ensure it is working).
> >>
> >> As you note there are various forks of QEMU that support device
> >> modelling but none of these features have been merged upstream and would
> >> likely need to assuage worries about such interfaces being used to avoid
> >> GPL compliance.
> >>
> >> What sort of devices are you looking to model? Are these existing
> >> devices or experimental/research things?
> >>
> >> --
> >> Alex Bennée
> >>
>
>
> --
> Alex Bennée
>

[-- Attachment #2: Type: text/html, Size: 3319 bytes --]

  reply	other threads:[~2020-08-10 13:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-10  5:06 QEMU Library support Pratik Parvati
2020-08-10  9:48 ` Alex Bennée
2020-08-10  9:59   ` Pratik Parvati
2020-08-10 10:20     ` Alex Bennée
2020-08-10 13:31       ` Pratik Parvati [this message]
2020-08-20  5:18   ` Pratik Parvati

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+aXn+G4EWAoGqgEuDW9j5dQSNJX2g31aGt521YL3MV9eyPzVg@mail.gmail.com \
    --to=pratikp@vayavyalabs.com \
    --cc=alex.bennee@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.