Device driver api

Device driver api

[Sam Price]

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

Is there a shared library interface in the works for writing firmware
device models without recompiling all of qemu?

I was reading through
https://sebastienbourdelin.com/2021/06/16/writing-a-custom-device-for-qemu/
but was wondering if there was a shared library approach where I could
build my device driver with some basic functions for getting memory ranges
this library supports / etc and then


https://elinux.org/images/9/95/Jw-ei-elc2010-final.pdf
10 years ago there was a presentation mentioning using dlopen to do thisd o
this type of thing.


-- 
Thank you,

Sam Price

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

Re: Device driver api

[Alex Bennée]

Sam Price <thesamprice@gmail.com> writes:

> Is there a shared library interface in the works for writing firmware
> device models without recompiling all of qemu?

No - but incremental builds should be fairly cheap especially if you
only build the target you care about, possibly with a reduced config.

> I was reading through 
> https://sebastienbourdelin.com/2021/06/16/writing-a-custom-device-for-qemu/

That's a nice write-up.

> but was wondering if there was a shared library approach where I could build my device driver with some basic functions for getting
> memory ranges this library supports / etc and then
>
> https://elinux.org/images/9/95/Jw-ei-elc2010-final.pdf
> 10 years ago there was a presentation mentioning using dlopen to do
> thisd o this type of thing.

The upstream community isn't really motivated to maintain an API for
external device models because ultimately we believe they are best
placed in the QEMU code, if not upstream in a fork. There are some forks
of QEMU which support things like SystemC models but so far none of that
has been submitted for upstream.

-- 
Alex Bennée

Re: Device driver api

[Peter Maydell]

On Thu, 24 Mar 2022 at 20:53, Alex Bennée <alex.bennee@linaro.org> wrote:
> The upstream community isn't really motivated to maintain an API for
> external device models because ultimately we believe they are best
> placed in the QEMU code, if not upstream in a fork. There are some forks
> of QEMU which support things like SystemC models but so far none of that
> has been submitted for upstream.

The SystemC stuff wasn't submitted upstream because we (upstream) decided
we didn't want it, incidentally.

-- PMM

Re: Device driver api

[Sam Price]

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

Thanks for all the insight.

My use case is for embedded programs interfacing with custom fpga
registers, and getting code coverage for these.
My device wouldn't have value for the community.
I'll play around with dlopen, and prototype some stuff on a fork.

Sam


On Thu, Mar 24, 2022 at 4:51 PM Alex Bennée <alex.bennee@linaro.org> wrote:

>
> Sam Price <thesamprice@gmail.com> writes:
>
> > Is there a shared library interface in the works for writing firmware
> > device models without recompiling all of qemu?
>
> No - but incremental builds should be fairly cheap especially if you
> only build the target you care about, possibly with a reduced config.
>
> > I was reading through
> >
> https://sebastienbourdelin.com/2021/06/16/writing-a-custom-device-for-qemu/
>
> That's a nice write-up.
>
> > but was wondering if there was a shared library approach where I could
> build my device driver with some basic functions for getting
> > memory ranges this library supports / etc and then
> >
> > https://elinux.org/images/9/95/Jw-ei-elc2010-final.pdf
> > 10 years ago there was a presentation mentioning using dlopen to do
> > thisd o this type of thing.
>
> The upstream community isn't really motivated to maintain an API for
> external device models because ultimately we believe they are best
> placed in the QEMU code, if not upstream in a fork. There are some forks
> of QEMU which support things like SystemC models but so far none of that
> has been submitted for upstream.
>
> --
> Alex Bennée
>


-- 
Thank you,

Sam Price
(707) 742-3726

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