[Qemu-devel] GSoC mentor summit QEMU users session

[Qemu-devel] GSoC mentor summit QEMU users session

[Alexander Graf]

Hi list,

During the GSoC mentor summit I held a small summit to find out what users of QEMU think could be improved and how they perceive QEMU.

The main point brought up was that people felt ignored when sending patches. From my experience, this usually happens when patches hit a maintainer free zone. One idea to address this issue was to just apply patches half-blindly when in such a maintainer-free zone. As long as the patch doesn't seem to have side effects, the worst it would do is fix an issue for someone contributing code and break someone not contributing. After a while, a new maintainer might rise this way.

We should also show people unmaintained areas. The conclusion was a wiki page with subsystems and status so people know what to expect. Maybe we could generate this from the MAINTAINERS file?

Also, an easy way of counterfighting the feeling ignored part is to tell people that they just hit an unmaintained area. There's nothing more frustrating than sending a patch and get no reply. Receiving a reply "Sorry, this area is unmaintained. Please find someone to review it." would already be enough for most people.

For 68k, Chris Johns from RTEMS stepped up and said he would happily maintainer that target. He will try to work on QEMU a bit more to gain trust and review patches.

The RTEMS guys use QEMU to do coverage testing of their kernel code. They run their test-cases and see if all of their code and branches have been hit. Adacore seems to have a patches version of QEMU to provide an easily parsable log file for that sort of thing. Might be a good idea to consolidate upstream. Patches welcome :)

A lot of people seem to also have code that doesn't make sense upstream, for example implementing a one-off device that only really matters for their own devboard which nobody else owns. For such cases, having a plugin framework would be handy. I interestingly enough got into the same discussion on LinuxCon with some QEMU downstreams.


Alex

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Peter Maydell]

On 29 October 2011 14:52, Alexander Graf <agraf@suse.de> wrote:
> We should also show people unmaintained areas. The conclusion was a wiki
> page with subsystems and status so people know what to expect. Maybe we
> could generate this from the MAINTAINERS file?

Sounds like a good idea, although I think we might need to expand
MAINTAINERS a bit -- I get the impression that there are a lot of
"little bits" that fall into the gaps between the top-level areas
marked out in MAINTAINERS.

> Also, an easy way of counterfighting the feeling ignored part is
> to tell people that they just hit an unmaintained area. There's
> nothing more frustrating than sending a patch and get no reply.
> Receiving a reply "Sorry, this area is unmaintained. Please find
> someone to review it." would already be enough for most people.

The difficulty that strikes me with this is that I'm not sure any
one person can reliably look at a patch and say "that's for an
unmaintained area" (at least, I know what areas I can review but
I have no idea about everybody else...) So you can only really
tell by default, ie if the patch sits for a few weeks without
any reply...

> A lot of people seem to also have code that doesn't make sense
> upstream, for example implementing a one-off device that only
> really matters for their own devboard which nobody else owns.
> For such cases, having a plugin framework would be handy. I
> interestingly enough got into the same discussion on LinuxCon
> with some QEMU downstreams.

If we get the qdev rework done then I think we're probably in
a better position to have a plugin framework for devices. (There
are some issues about API and ABI stability guarantees, of course.)

-- PMM

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Alexander Graf]

On 31.10.2011, at 06:12, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 29 October 2011 14:52, Alexander Graf <agraf@suse.de> wrote:
>> We should also show people unmaintained areas. The conclusion was a wiki
>> page with subsystems and status so people know what to expect. Maybe we
>> could generate this from the MAINTAINERS file?
> 
> Sounds like a good idea, although I think we might need to expand
> MAINTAINERS a bit -- I get the impression that there are a lot of
> "little bits" that fall into the gaps between the top-level areas
> marked out in MAINTAINERS.

True. We do however have file path matches, so we could easily find unmaintained files.

> 
>> Also, an easy way of counterfighting the feeling ignored part is
>> to tell people that they just hit an unmaintained area. There's
>> nothing more frustrating than sending a patch and get no reply.
>> Receiving a reply "Sorry, this area is unmaintained. Please find
>> someone to review it." would already be enough for most people.
> 
> The difficulty that strikes me with this is that I'm not sure any
> one person can reliably look at a patch and say "that's for an
> unmaintained area" (at least, I know what areas I can review but
> I have no idea about everybody else...) So you can only really
> tell by default, ie if the patch sits for a few weeks without
> any reply...

See above. I think we could script this :)

> 
>> A lot of people seem to also have code that doesn't make sense
>> upstream, for example implementing a one-off device that only
>> really matters for their own devboard which nobody else owns.
>> For such cases, having a plugin framework would be handy. I
>> interestingly enough got into the same discussion on LinuxCon
>> with some QEMU downstreams.
> 
> If we get the qdev rework done then I think we're probably in
> a better position to have a plugin framework for devices. (There
> are some issues about API and ABI stability guarantees, of course.)

I'm not sure why we should. We could just follow the Linux kernel model and merely expose what's there. New version means new API.

Remember, I don't want this for commercial fire-and-forget device models. I want it for stuff that's either too unclean or too useless for upstream :).


Alex

> 

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Peter Maydell]

On 1 November 2011 00:08, Alexander Graf <agraf@suse.de> wrote:
> On 31.10.2011, at 06:12, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 29 October 2011 14:52, Alexander Graf <agraf@suse.de> wrote:
>>> We should also show people unmaintained areas. The conclusion was a wiki
>>> page with subsystems and status so people know what to expect. Maybe we
>>> could generate this from the MAINTAINERS file?
>>
>> Sounds like a good idea, although I think we might need to expand
>> MAINTAINERS a bit -- I get the impression that there are a lot of
>> "little bits" that fall into the gaps between the top-level areas
>> marked out in MAINTAINERS.
>
> True. We do however have file path matches, so we could easily find unmaintained files.

We'd need to expand MAINTAINERS to be a lot more comprehensive and
detailed than it is now (not necessarily a bad plan). It also doesn't
deal with the "this area is maintained but the maintainer seems to
have been busy for the last three months" issue.

I guess we could try it and see how it worked.

> See above. I think we could script this :)

I think you also want to have some sort of scripting of whether
and what you were still leaving behind -- ie try to identify the
patches which your script thought were maintained but which
still didn't get any response.

(A mildly enhanced version of patchwork might do for that.)

>> If we get the qdev rework done then I think we're probably in
>> a better position to have a plugin framework for devices. (There
>> are some issues about API and ABI stability guarantees, of course.)
>
> I'm not sure why we should. We could just follow the Linux kernel
> model and merely expose what's there. New version means new API.

The "issue" is whether you try to provide any stability guarantee :-)
"We don't" is one answer, but of course it does reduce the utility.

> Remember, I don't want this for commercial fire-and-forget device
> models. I want it for stuff that's either too unclean or too
> useless for upstream :).

I'm not sure that it helps very much for this use case -- if you
have to update and rebuild for any new qemu then you might as well
have it built in (a private copy of) the qemu source tree, because
it'll just be some new files and a patch to the Makefile.

-- PMM

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Alexander Graf]

On 31.10.2011, at 18:35, Peter Maydell wrote:

> On 1 November 2011 00:08, Alexander Graf <agraf@suse.de> wrote:
>> On 31.10.2011, at 06:12, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> On 29 October 2011 14:52, Alexander Graf <agraf@suse.de> wrote:
>>>> We should also show people unmaintained areas. The conclusion was a wiki
>>>> page with subsystems and status so people know what to expect. Maybe we
>>>> could generate this from the MAINTAINERS file?
>>> 
>>> Sounds like a good idea, although I think we might need to expand
>>> MAINTAINERS a bit -- I get the impression that there are a lot of
>>> "little bits" that fall into the gaps between the top-level areas
>>> marked out in MAINTAINERS.
>> 
>> True. We do however have file path matches, so we could easily find unmaintained files.
> 
> We'd need to expand MAINTAINERS to be a lot more comprehensive and
> detailed than it is now (not necessarily a bad plan). It also doesn't
> deal with the "this area is maintained but the maintainer seems to
> have been busy for the last three months" issue.
> 
> I guess we could try it and see how it worked.
> 
>> See above. I think we could script this :)
> 
> I think you also want to have some sort of scripting of whether
> and what you were still leaving behind -- ie try to identify the
> patches which your script thought were maintained but which
> still didn't get any response.
> 
> (A mildly enhanced version of patchwork might do for that.)

Phew, eager goals :). I like the idea though!

> 
>>> If we get the qdev rework done then I think we're probably in
>>> a better position to have a plugin framework for devices. (There
>>> are some issues about API and ABI stability guarantees, of course.)
>> 
>> I'm not sure why we should. We could just follow the Linux kernel
>> model and merely expose what's there. New version means new API.
> 
> The "issue" is whether you try to provide any stability guarantee :-)
> "We don't" is one answer, but of course it does reduce the utility.

Sure, but reduced utility is a good starting point. It's certainly better than no utility :).

> 
>> Remember, I don't want this for commercial fire-and-forget device
>> models. I want it for stuff that's either too unclean or too
>> useless for upstream :).
> 
> I'm not sure that it helps very much for this use case -- if you
> have to update and rebuild for any new qemu then you might as well
> have it built in (a private copy of) the qemu source tree, because
> it'll just be some new files and a patch to the Makefile.

The main improvement is that you could enhance distro versions of QEMU. And inside a stable version we would also stay ABI compatible usually.


Alex

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Gerd Hoffmann]

  Hi,

> If we get the qdev rework done then I think we're probably in
> a better position to have a plugin framework for devices. (There
> are some issues about API and ABI stability guarantees, of course.)

One of the qdev intended benefits is to have pretty much self-contained
device emulation.  If doesn't work equally well everythere.  For alot of
-- for example -- PCI devices it does work nicely though.  Adding a
device is simply a matter of dropping a file into the tree and a line
into the Makefile and you are done.  The device is available to be used
via -device.  So the cost of maintaining stuff out-of-tree isn't that
big as you almost never have patch conflict issues.

For embedded stuff it is usually a bit trickier as the device
interconnects are hard-coded in the board creation bits and devices
can't be hooked up using -device (or some other generic mechanism which
uses -- say -- device trees) ...

cheers,
  Gerd

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Andreas Färber]

Am 29.10.2011 15:52, schrieb Alexander Graf:
> We should also show people unmaintained areas. The conclusion was a wiki page with subsystems and status so people know what to expect.

We already have: http://wiki.qemu.org/Features

And in some places it used to defer from MAINTAINERS.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Anthony Liguori]

On 11/01/2011 09:28 AM, Andreas Färber wrote:
> Am 29.10.2011 15:52, schrieb Alexander Graf:
>> We should also show people unmaintained areas. The conclusion was a wiki page with subsystems and status so people know what to expect.
>
> We already have: http://wiki.qemu.org/Features
>
> And in some places it used to defer from MAINTAINERS.

I think it's better to use MAINTAINERS to coordinate this information.  If 
someone can take a pass at checking it for accuracy and adding some unmaintained 
subsystems, I'm sure that would go a long ways.

Regards,

Anthony Liguori

>
> Andreas
>

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Chris Johns]

On 1/11/11 9:05 PM, Gerd Hoffmann wrote:
> Adding a
> device is simply a matter of dropping a file into the tree and a line
> into the Makefile and you are done.  The device is available to be used
> via -device.  So the cost of maintaining stuff out-of-tree isn't that
> big as you almost never have patch conflict issues.
>

The concern here is when something goes wrong. A user who does not know 
qemu's source picks up the source for a driver they would like to use 
how-ever the qemu they build does not work as they expect. With a binary 
blob they question their set up or options, with something they build 
there is more doubt about the nature of the failure.

Chris

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Fabien Chouteau]

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

On 29/10/2011 15:52, Alexander Graf wrote:
> The RTEMS guys use QEMU to do coverage testing of their kernel code.
> They run their test-cases and see if all of their code and branches
> have been hit. Adacore seems to have a patches version of QEMU to
> provide an easily parsable log file for that sort of thing. Might be a
> good idea to consolidate upstream. Patches welcome :)

That's right we do have a coverage analysis solution based on Qemu.
Execution traces generated by Qemu are analyzed by the GNATcoverage
tool to provide object, statement, decision or Modified
Condition/Decision coverage analysis.

The main interest of Qemu is to provide execution traces without
code instrumentation.

Alex, it is of course in our plans to submit patches to the upstream Qemu ;)

I give you some pointers if you want to find more on GNATcoverage (technical stuff :)

 * GNATcoverage is hosted on forge.open-do.org. You can checkout the
   repository with:

     $ svn checkout svn://scm.forge.open-do.org/scmrepos/svn/couverture/trunk/couverture

   From there, you have
     * the tool source tree in "tools"
     * a synthesis article in "publications" : 201005-erts2.pdf

 * GNATcov's documentation attached to this email

Regards,

-- 
Fabien Chouteau

[-- Attachment #2: gnatcov.pdf --]
[-- Type: application/pdf, Size: 336616 bytes --]

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Fabien Chouteau]

On 31/10/2011 14:12, Peter Maydell wrote:
> On 29 October 2011 14:52, Alexander Graf <agraf@suse.de> wrote:
>> A lot of people seem to also have code that doesn't make sense
>> upstream, for example implementing a one-off device that only
>> really matters for their own devboard which nobody else owns.
>> For such cases, having a plugin framework would be handy. I
>> interestingly enough got into the same discussion on LinuxCon
>> with some QEMU downstreams.
> 
> If we get the qdev rework done then I think we're probably in
> a better position to have a plugin framework for devices. (There
> are some issues about API and ABI stability guarantees, of course.)
> 

Interesting, we have a "plug-in" implementation in our Qemu branch. It
allows a plug-ins to register io_areas, read and write callback, trigger
interrupts, etc...

Qemu provides this interface to the plug-in:

struct QemuPlugin_Emulator
{
    uint64_t (*get_time)(QemuPlugin_ClockType clock);


    uint32_t (*add_event)(uint64_t              expire_time,
                          QemuPlugin_ClockType  clock,
                          uint32_t              event_id,
                          EventCallback         event,
                          void                 *opaque);

    uint32_t (*remove_event)(QemuPlugin_ClockType clock,
                             uint32_t             event_id);

    uint32_t (*set_irq)(uint32_t line, uint32_t level);

    uint32_t (*dma_read)(void          *dest,
                         target_addr_t  addr,
                         int            size);

    uint32_t (*dma_write)(void          *src,
                          target_addr_t  addr,
                          int            size);

    uint32_t (*attach_device)(QemuPlugin_DeviceInfo *dev);

    uint32_t version;
};

and the plug-in provides this interface to Qemu:

typedef uint32_t io_read_fn(void *opaque, target_addr_t addr, uint32_t size);

typedef void     io_write_fn(void          *opaque,
                             target_addr_t  addr,
                             uint32_t       size,
                             uint32_t       val);

typedef void reset_fn(void *opaque);
typedef void init_fn(void *opaque);
typedef void exit_fn(void *opaque);

typedef struct QemuPlugin_DeviceInfo
{
    uint32_t version;

    uint32_t vendor_id;
    uint32_t device_id;
    char     name[NAME_LENGTH];
    char     desc[DESC_LENGTH];

    void *opaque;

    io_read_fn  *io_read;
    io_write_fn *io_write;

    reset_fn *pdevice_reset;
    init_fn  *pdevice_init;
    exit_fn  *pdevice_exit;

    uint32_t nr_iomem;
    struct QemuPlugin_IOMemory
    {
        target_addr_t base;
        target_addr_t size;
    } iomem[MAX_IOMEM];
} QemuPlugin_DeviceInfo;

-- 
Fabien Chouteau

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Jan Kiszka]

On 2011-11-02 18:44, Fabien Chouteau wrote:
> On 31/10/2011 14:12, Peter Maydell wrote:
>> On 29 October 2011 14:52, Alexander Graf <agraf@suse.de> wrote:
>>> A lot of people seem to also have code that doesn't make sense
>>> upstream, for example implementing a one-off device that only
>>> really matters for their own devboard which nobody else owns.
>>> For such cases, having a plugin framework would be handy. I
>>> interestingly enough got into the same discussion on LinuxCon
>>> with some QEMU downstreams.
>>
>> If we get the qdev rework done then I think we're probably in
>> a better position to have a plugin framework for devices. (There
>> are some issues about API and ABI stability guarantees, of course.)
>>
> 
> Interesting, we have a "plug-in" implementation in our Qemu branch. It

We have a "plugin" model here as well. It's really simple: the plugin is
loaded dynamically into the QEMU process and can access any global
function and variable. Of course, this breaks regularly.

> allows a plug-ins to register io_areas, read and write callback, trigger
> interrupts, etc...
> 
> Qemu provides this interface to the plug-in:
> 
> struct QemuPlugin_Emulator
> {
>     uint64_t (*get_time)(QemuPlugin_ClockType clock);
> 
> 
>     uint32_t (*add_event)(uint64_t              expire_time,
>                           QemuPlugin_ClockType  clock,
>                           uint32_t              event_id,
>                           EventCallback         event,
>                           void                 *opaque);
> 
>     uint32_t (*remove_event)(QemuPlugin_ClockType clock,
>                              uint32_t             event_id);
> 
>     uint32_t (*set_irq)(uint32_t line, uint32_t level);
> 
>     uint32_t (*dma_read)(void          *dest,
>                          target_addr_t  addr,
>                          int            size);
> 
>     uint32_t (*dma_write)(void          *src,
>                           target_addr_t  addr,
>                           int            size);
> 
>     uint32_t (*attach_device)(QemuPlugin_DeviceInfo *dev);
> 
>     uint32_t version;
> };
> 
> and the plug-in provides this interface to Qemu:
> 
> typedef uint32_t io_read_fn(void *opaque, target_addr_t addr, uint32_t size);
> 
> typedef void     io_write_fn(void          *opaque,
>                              target_addr_t  addr,
>                              uint32_t       size,
>                              uint32_t       val);
> 
> typedef void reset_fn(void *opaque);
> typedef void init_fn(void *opaque);
> typedef void exit_fn(void *opaque);
> 
> typedef struct QemuPlugin_DeviceInfo
> {
>     uint32_t version;
> 
>     uint32_t vendor_id;
>     uint32_t device_id;
>     char     name[NAME_LENGTH];
>     char     desc[DESC_LENGTH];
> 
>     void *opaque;
> 
>     io_read_fn  *io_read;
>     io_write_fn *io_write;
> 
>     reset_fn *pdevice_reset;
>     init_fn  *pdevice_init;
>     exit_fn  *pdevice_exit;
> 
>     uint32_t nr_iomem;
>     struct QemuPlugin_IOMemory
>     {
>         target_addr_t base;
>         target_addr_t size;
>     } iomem[MAX_IOMEM];
> } QemuPlugin_DeviceInfo;
> 

To implement, e.g., a custom PCI device, you still need a stub in QEMU
with that model. But you want access to the PCI layer, the MSI services,
etc. anyway - unless you plan to reinvent all that wheels.

Another example: How do you model a USB device this way?

IOW, we need a plugin model that can interact with other components at
their interface level, not only through a central, naturally restricted one.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Anthony Liguori]

On 11/02/2011 01:17 PM, Jan Kiszka wrote:
> On 2011-11-02 18:44, Fabien Chouteau wrote:
>> On 31/10/2011 14:12, Peter Maydell wrote:
>>> On 29 October 2011 14:52, Alexander Graf<agraf@suse.de>  wrote:
>>>> A lot of people seem to also have code that doesn't make sense
>>>> upstream, for example implementing a one-off device that only
>>>> really matters for their own devboard which nobody else owns.
>>>> For such cases, having a plugin framework would be handy. I
>>>> interestingly enough got into the same discussion on LinuxCon
>>>> with some QEMU downstreams.
>>>
>>> If we get the qdev rework done then I think we're probably in
>>> a better position to have a plugin framework for devices. (There
>>> are some issues about API and ABI stability guarantees, of course.)
>>>
>>
>> Interesting, we have a "plug-in" implementation in our Qemu branch. It
>
> We have a "plugin" model here as well. It's really simple: the plugin is
> loaded dynamically into the QEMU process and can access any global
> function and variable. Of course, this breaks regularly.

Yes, this is the Right Model.

All of the work is in making the interfaces not break regularly.  Loading a 
shared object is easy enough.

Regards,

Anthony Liguori

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Alexander Graf]

Anthony Liguori wrote:
> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>> On 2011-11-02 18:44, Fabien Chouteau wrote:
>>> On 31/10/2011 14:12, Peter Maydell wrote:
>>>> On 29 October 2011 14:52, Alexander Graf<agraf@suse.de>  wrote:
>>>>> A lot of people seem to also have code that doesn't make sense
>>>>> upstream, for example implementing a one-off device that only
>>>>> really matters for their own devboard which nobody else owns.
>>>>> For such cases, having a plugin framework would be handy. I
>>>>> interestingly enough got into the same discussion on LinuxCon
>>>>> with some QEMU downstreams.
>>>>
>>>> If we get the qdev rework done then I think we're probably in
>>>> a better position to have a plugin framework for devices. (There
>>>> are some issues about API and ABI stability guarantees, of course.)
>>>>
>>>
>>> Interesting, we have a "plug-in" implementation in our Qemu branch. It
>>
>> We have a "plugin" model here as well. It's really simple: the plugin is
>> loaded dynamically into the QEMU process and can access any global
>> function and variable. Of course, this breaks regularly.
>
> Yes, this is the Right Model.
>
> All of the work is in making the interfaces not break regularly. 
> Loading a shared object is easy enough.

I agree. In fact, we could even do it the same way as the kernel and
build all our internal hw pieces as shared objects.

Then users who want to cut down QEMU can just remove .so files instead
of messing with the build system or code.


Alex

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Jan Kiszka]

On 2011-11-02 19:34, Alexander Graf wrote:
> Anthony Liguori wrote:
>> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>>> On 2011-11-02 18:44, Fabien Chouteau wrote:
>>>> On 31/10/2011 14:12, Peter Maydell wrote:
>>>>> On 29 October 2011 14:52, Alexander Graf<agraf@suse.de>  wrote:
>>>>>> A lot of people seem to also have code that doesn't make sense
>>>>>> upstream, for example implementing a one-off device that only
>>>>>> really matters for their own devboard which nobody else owns.
>>>>>> For such cases, having a plugin framework would be handy. I
>>>>>> interestingly enough got into the same discussion on LinuxCon
>>>>>> with some QEMU downstreams.
>>>>>
>>>>> If we get the qdev rework done then I think we're probably in
>>>>> a better position to have a plugin framework for devices. (There
>>>>> are some issues about API and ABI stability guarantees, of course.)
>>>>>
>>>>
>>>> Interesting, we have a "plug-in" implementation in our Qemu branch. It
>>>
>>> We have a "plugin" model here as well. It's really simple: the plugin is
>>> loaded dynamically into the QEMU process and can access any global
>>> function and variable. Of course, this breaks regularly.
>>
>> Yes, this is the Right Model.
>>
>> All of the work is in making the interfaces not break regularly. 
>> Loading a shared object is easy enough.
> 
> I agree. In fact, we could even do it the same way as the kernel and
> build all our internal hw pieces as shared objects.
> 
> Then users who want to cut down QEMU can just remove .so files instead
> of messing with the build system or code.

We should also be able to establish an EXPORT_SYMBOL concept, ie. only
export those functions that are supposed to be part of a component API.
Will be some work initially, but should be off long term, both to QEMU
in maintaining stable APIs and to external components in using the
proper ones.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Alexander Graf]

Jan Kiszka wrote:
> On 2011-11-02 19:34, Alexander Graf wrote:
>   
>> Anthony Liguori wrote:
>>     
>>> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>>>       
>>>> On 2011-11-02 18:44, Fabien Chouteau wrote:
>>>>         
>>>>> On 31/10/2011 14:12, Peter Maydell wrote:
>>>>>           
>>>>>> On 29 October 2011 14:52, Alexander Graf<agraf@suse.de>  wrote:
>>>>>>             
>>>>>>> A lot of people seem to also have code that doesn't make sense
>>>>>>> upstream, for example implementing a one-off device that only
>>>>>>> really matters for their own devboard which nobody else owns.
>>>>>>> For such cases, having a plugin framework would be handy. I
>>>>>>> interestingly enough got into the same discussion on LinuxCon
>>>>>>> with some QEMU downstreams.
>>>>>>>               
>>>>>> If we get the qdev rework done then I think we're probably in
>>>>>> a better position to have a plugin framework for devices. (There
>>>>>> are some issues about API and ABI stability guarantees, of course.)
>>>>>>
>>>>>>             
>>>>> Interesting, we have a "plug-in" implementation in our Qemu branch. It
>>>>>           
>>>> We have a "plugin" model here as well. It's really simple: the plugin is
>>>> loaded dynamically into the QEMU process and can access any global
>>>> function and variable. Of course, this breaks regularly.
>>>>         
>>> Yes, this is the Right Model.
>>>
>>> All of the work is in making the interfaces not break regularly. 
>>> Loading a shared object is easy enough.
>>>       
>> I agree. In fact, we could even do it the same way as the kernel and
>> build all our internal hw pieces as shared objects.
>>
>> Then users who want to cut down QEMU can just remove .so files instead
>> of messing with the build system or code.
>>     
>
> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
> export those functions that are supposed to be part of a component API.
> Will be some work initially, but should be off long term, both to QEMU
> in maintaining stable APIs and to external components in using the
> proper ones.
>   

Yes. IOW, let's go down the same road as Linux. It works well for them,
why not for us?


Alex

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Anthony Liguori]

On 11/02/2011 01:46 PM, Jan Kiszka wrote:
> On 2011-11-02 19:34, Alexander Graf wrote:
>> Anthony Liguori wrote:
>>> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>>>> On 2011-11-02 18:44, Fabien Chouteau wrote:
>>>>> On 31/10/2011 14:12, Peter Maydell wrote:
>>>>>> On 29 October 2011 14:52, Alexander Graf<agraf@suse.de>   wrote:
>>>>>>> A lot of people seem to also have code that doesn't make sense
>>>>>>> upstream, for example implementing a one-off device that only
>>>>>>> really matters for their own devboard which nobody else owns.
>>>>>>> For such cases, having a plugin framework would be handy. I
>>>>>>> interestingly enough got into the same discussion on LinuxCon
>>>>>>> with some QEMU downstreams.
>>>>>>
>>>>>> If we get the qdev rework done then I think we're probably in
>>>>>> a better position to have a plugin framework for devices. (There
>>>>>> are some issues about API and ABI stability guarantees, of course.)
>>>>>>
>>>>>
>>>>> Interesting, we have a "plug-in" implementation in our Qemu branch. It
>>>>
>>>> We have a "plugin" model here as well. It's really simple: the plugin is
>>>> loaded dynamically into the QEMU process and can access any global
>>>> function and variable. Of course, this breaks regularly.
>>>
>>> Yes, this is the Right Model.
>>>
>>> All of the work is in making the interfaces not break regularly.
>>> Loading a shared object is easy enough.
>>
>> I agree. In fact, we could even do it the same way as the kernel and
>> build all our internal hw pieces as shared objects.
>>
>> Then users who want to cut down QEMU can just remove .so files instead
>> of messing with the build system or code.
>
> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
> export those functions that are supposed to be part of a component API.
> Will be some work initially, but should be off long term, both to QEMU
> in maintaining stable APIs and to external components in using the
> proper ones.

Not at first.  We don't need yet another interface that we have to try to 
maintain.  Until things stabilize internally, the module interface should be 
completely unstable.

Regards,

Anthony Liguori

>
> Jan
>

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Anthony Liguori]

On 11/02/2011 01:34 PM, Alexander Graf wrote:
> Anthony Liguori wrote:
>> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>>> On 2011-11-02 18:44, Fabien Chouteau wrote:
>>>> On 31/10/2011 14:12, Peter Maydell wrote:
>>>>> On 29 October 2011 14:52, Alexander Graf<agraf@suse.de>   wrote:
>>>>>> A lot of people seem to also have code that doesn't make sense
>>>>>> upstream, for example implementing a one-off device that only
>>>>>> really matters for their own devboard which nobody else owns.
>>>>>> For such cases, having a plugin framework would be handy. I
>>>>>> interestingly enough got into the same discussion on LinuxCon
>>>>>> with some QEMU downstreams.
>>>>>
>>>>> If we get the qdev rework done then I think we're probably in
>>>>> a better position to have a plugin framework for devices. (There
>>>>> are some issues about API and ABI stability guarantees, of course.)
>>>>>
>>>>
>>>> Interesting, we have a "plug-in" implementation in our Qemu branch. It
>>>
>>> We have a "plugin" model here as well. It's really simple: the plugin is
>>> loaded dynamically into the QEMU process and can access any global
>>> function and variable. Of course, this breaks regularly.
>>
>> Yes, this is the Right Model.
>>
>> All of the work is in making the interfaces not break regularly.
>> Loading a shared object is easy enough.
>
> I agree. In fact, we could even do it the same way as the kernel and
> build all our internal hw pieces as shared objects.
>
> Then users who want to cut down QEMU can just remove .so files instead
> of messing with the build system or code.

This is totally untested and won't probably build, but we can do something like 
this.  We should also follow 
http://www.gnu.org/prep/standards/html_node/Dynamic-Plug_002dIn-Interfaces.html

diff --git a/hw/qdev.c b/hw/qdev.c
index 50976dd..1d5aea7 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -58,6 +58,7 @@ static DeviceInfo *qdev_find_info(BusInfo *bus_info, const cha
  {
      DeviceInfo *info;

+again:
      /* first check device names */
      for (info = device_info_list; info != NULL; info = info->next) {
          if (bus_info && info->bus_info != bus_info)
@@ -77,6 +78,20 @@ static DeviceInfo *qdev_find_info(BusInfo *bus_info, const ch
              continue;
          return info;
      }
+
+    /* try to load an appropriately named module */
+    {
+        char *path = g_module_build_path(PREFIX, info->name);
+        GModule *mod = g_module_open(path, G_MODULE_BIND_LOCAL);
+        void (*init)(void);
+
+        if (g_module_symbol(mod, "mod_init", &init)) {
+            init();
+            goto again;
+        }
+    }
+
+
      return NULL;
  }

Regards,

Anthony Liguori

>
>
> Alex
>
>

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Jan Kiszka]

On 2011-11-02 19:50, Anthony Liguori wrote:
> On 11/02/2011 01:46 PM, Jan Kiszka wrote:
>> On 2011-11-02 19:34, Alexander Graf wrote:
>>> Anthony Liguori wrote:
>>>> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>>>>> On 2011-11-02 18:44, Fabien Chouteau wrote:
>>>>>> On 31/10/2011 14:12, Peter Maydell wrote:
>>>>>>> On 29 October 2011 14:52, Alexander Graf<agraf@suse.de>   wrote:
>>>>>>>> A lot of people seem to also have code that doesn't make sense
>>>>>>>> upstream, for example implementing a one-off device that only
>>>>>>>> really matters for their own devboard which nobody else owns.
>>>>>>>> For such cases, having a plugin framework would be handy. I
>>>>>>>> interestingly enough got into the same discussion on LinuxCon
>>>>>>>> with some QEMU downstreams.
>>>>>>>
>>>>>>> If we get the qdev rework done then I think we're probably in
>>>>>>> a better position to have a plugin framework for devices. (There
>>>>>>> are some issues about API and ABI stability guarantees, of course.)
>>>>>>>
>>>>>>
>>>>>> Interesting, we have a "plug-in" implementation in our Qemu branch. It
>>>>>
>>>>> We have a "plugin" model here as well. It's really simple: the plugin is
>>>>> loaded dynamically into the QEMU process and can access any global
>>>>> function and variable. Of course, this breaks regularly.
>>>>
>>>> Yes, this is the Right Model.
>>>>
>>>> All of the work is in making the interfaces not break regularly.
>>>> Loading a shared object is easy enough.
>>>
>>> I agree. In fact, we could even do it the same way as the kernel and
>>> build all our internal hw pieces as shared objects.
>>>
>>> Then users who want to cut down QEMU can just remove .so files instead
>>> of messing with the build system or code.
>>
>> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
>> export those functions that are supposed to be part of a component API.
>> Will be some work initially, but should be off long term, both to QEMU
>> in maintaining stable APIs and to external components in using the
>> proper ones.
> 
> Not at first.  We don't need yet another interface that we have to try to 
> maintain.  Until things stabilize internally, the module interface should be 
> completely unstable.

For sure. It would not work out of the box anyway as way too many
functions would have to be marked - and way too much code refactored first.

We could start with a MAY_BECOME_API_SYMBOL marker that does nothing
except commenting the plan.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Peter Maydell]

On 2 November 2011 18:47, Alexander Graf <agraf@suse.de> wrote:
> Jan Kiszka wrote:
>> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
>> export those functions that are supposed to be part of a component API.
>> Will be some work initially, but should be off long term, both to QEMU
>> in maintaining stable APIs and to external components in using the
>> proper ones.

> Yes. IOW, let's go down the same road as Linux. It works well for them,
> why not for us?

I'd rather see us have a decent usable API for implementing devices
*inside* the QEMU source tree before we start thinking about having
one for devices outside the tree...

-- PMM

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Alexander Graf]

Peter Maydell wrote:
> On 2 November 2011 18:47, Alexander Graf <agraf@suse.de> wrote:
>   
>> Jan Kiszka wrote:
>>     
>>> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
>>> export those functions that are supposed to be part of a component API.
>>> Will be some work initially, but should be off long term, both to QEMU
>>> in maintaining stable APIs and to external components in using the
>>> proper ones.
>>>       
>
>   
>> Yes. IOW, let's go down the same road as Linux. It works well for them,
>> why not for us?
>>     
>
> I'd rather see us have a decent usable API for implementing devices
> *inside* the QEMU source tree before we start thinking about having
> one for devices outside the tree...
>   
Right. That's exactly what Linux does. On Linux, you have EXPORT_SYMBOL
and EXPORT_SYMBOL_GPL. The former is considered reasonably stable. The
latter can change even in minor revisions.

So the obvious thing to do would be to export everything, but mark it
unstable and then mark things stable as we go in and actually consider
them stable. And only consider them stable for a limited time.

Alex

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Anthony Liguori]

On 11/02/2011 02:27 PM, Alexander Graf wrote:
> Peter Maydell wrote:
>> On 2 November 2011 18:47, Alexander Graf<agraf@suse.de>  wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
>>>> export those functions that are supposed to be part of a component API.
>>>> Will be some work initially, but should be off long term, both to QEMU
>>>> in maintaining stable APIs and to external components in using the
>>>> proper ones.
>>>>
>>
>>
>>> Yes. IOW, let's go down the same road as Linux. It works well for them,
>>> why not for us?
>>>
>>
>> I'd rather see us have a decent usable API for implementing devices
>> *inside* the QEMU source tree before we start thinking about having
>> one for devices outside the tree...
>>
> Right. That's exactly what Linux does. On Linux, you have EXPORT_SYMBOL
> and EXPORT_SYMBOL_GPL. The former is considered reasonably stable. The
> latter can change even in minor revisions.

No... neither are stable.

The difference is historical and has to do with licensing, not stability.

> So the obvious thing to do would be to export everything, but mark it
> unstable and then mark things stable as we go in and actually consider
> them stable. And only consider them stable for a limited time.

For the record, I'm opposed to ever having a stable plugin API.

We aren't a closed source product.  If people want to have to keep up with our 
changing internal interfaces, they can get their code merged upstream.

Regards,

Anthony Liguori

> Alex
>
>

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Blue Swirl]

On Wed, Nov 2, 2011 at 19:35, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 11/02/2011 02:27 PM, Alexander Graf wrote:
>>
>> Peter Maydell wrote:
>>>
>>> On 2 November 2011 18:47, Alexander Graf<agraf@suse.de>  wrote:
>>>
>>>> Jan Kiszka wrote:
>>>>
>>>>> We should also be able to establish an EXPORT_SYMBOL concept, ie. only
>>>>> export those functions that are supposed to be part of a component API.
>>>>> Will be some work initially, but should be off long term, both to QEMU
>>>>> in maintaining stable APIs and to external components in using the
>>>>> proper ones.
>>>>>
>>>
>>>
>>>> Yes. IOW, let's go down the same road as Linux. It works well for them,
>>>> why not for us?
>>>>
>>>
>>> I'd rather see us have a decent usable API for implementing devices
>>> *inside* the QEMU source tree before we start thinking about having
>>> one for devices outside the tree...
>>>
>> Right. That's exactly what Linux does. On Linux, you have EXPORT_SYMBOL
>> and EXPORT_SYMBOL_GPL. The former is considered reasonably stable. The
>> latter can change even in minor revisions.
>
> No... neither are stable.
>
> The difference is historical and has to do with licensing, not stability.
>
>> So the obvious thing to do would be to export everything, but mark it
>> unstable and then mark things stable as we go in and actually consider
>> them stable. And only consider them stable for a limited time.
>
> For the record, I'm opposed to ever having a stable plugin API.
>
> We aren't a closed source product.  If people want to have to keep up with
> our changing internal interfaces, they can get their code merged upstream.

Fully agree. I don't even think there can be any benefit for us from a
plugin system, only API/ABI legacy maintenance effort and limitations
to architectural changes. All benefits are external.

There are other useful paths available for external users, QAPI, QMP,
GDBstub, maybe also instrumentation in the future.

Perhaps we could add a 'contrib' directory where new stuff could be
added easily to make life outside better. It could also be used to
clean up bitrotten devices and functionality from core. Marking things
with deprecated attributes or something like CONFIG_EXPERIMENTAL in
Linux could also help.

> Regards,
>
> Anthony Liguori
>
>> Alex
>>
>>
>
>
>

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Anthony Liguori]

On 11/02/2011 03:24 PM, Blue Swirl wrote:
> On Wed, Nov 2, 2011 at 19:35, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> For the record, I'm opposed to ever having a stable plugin API.
>>
>> We aren't a closed source product.  If people want to have to keep up with
>> our changing internal interfaces, they can get their code merged upstream.
>
> Fully agree. I don't even think there can be any benefit for us from a
> plugin system, only API/ABI legacy maintenance effort and limitations
> to architectural changes. All benefits are external.
>
> There are other useful paths available for external users, QAPI, QMP,
> GDBstub, maybe also instrumentation in the future.
>
> Perhaps we could add a 'contrib' directory where new stuff could be
> added easily to make life outside better. It could also be used to
> clean up bitrotten devices and functionality from core. Marking things
> with deprecated attributes or something like CONFIG_EXPERIMENTAL in
> Linux could also help.

I like having dynamic modules for a few reasons:

1) It makes us start thinking in a more modular fashion.  We're getting close to 
a million lines of code--we really do need to do a better job at modularity if 
we want to keep growing at this rate.

2) It makes life a bit nicer for distributions as we grow optional dependencies. 
  Having a single QEMU binary that links against libtpms and libspice means that 
a distro needs to make libtpms/libspice a Requires in the package.  libspice has 
a ton of dependencies which makes QEMU have a ton of hard dependencies. 
Instead, if a distro can build a QEMU package and a qemu-spice package, the 
libspice dependency can be isolated to the qemu-spice package.

That means you can install QEMU on your server without pulling in all sorts of 
ffmpeg stuff if you don't care about Spice.  I'm picking on Spice here, but 
there are lots of other examples here (vde2, libbaum, SDL, etc.).

3) It lets people do out-of-tree development without forking the whole tree.  As 
much as I don't like out-of-tree development, it's a reality.  If things like 
the Android SDK could be done just as a set of plugins, it would be better for 
all of us.

4) We'll hopefully get to a point where most of what we do can be demand loaded. 
  This helps us establish a smaller in memory base which is important when it 
comes to Security Certifications[1].

[1] Security Certification has only an arguable relationship with actual 
security but it is, nonetheless, and important consideration.

Regards,

Anthony Liguori

>
>> Regards,
>>
>> Anthony Liguori
>>
>>> Alex
>>>
>>>
>>
>>
>>
>

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> On 11/02/2011 03:24 PM, Blue Swirl wrote:
>> On Wed, Nov 2, 2011 at 19:35, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>> For the record, I'm opposed to ever having a stable plugin API.
>>>
>>> We aren't a closed source product.  If people want to have to keep up with
>>> our changing internal interfaces, they can get their code merged upstream.
>>
>> Fully agree. I don't even think there can be any benefit for us from a
>> plugin system, only API/ABI legacy maintenance effort and limitations
>> to architectural changes. All benefits are external.
>>
>> There are other useful paths available for external users, QAPI, QMP,
>> GDBstub, maybe also instrumentation in the future.
>>
>> Perhaps we could add a 'contrib' directory where new stuff could be
>> added easily to make life outside better. It could also be used to
>> clean up bitrotten devices and functionality from core. Marking things
>> with deprecated attributes or something like CONFIG_EXPERIMENTAL in
>> Linux could also help.
>
> I like having dynamic modules for a few reasons:
>
> 1) It makes us start thinking in a more modular fashion.  We're
> getting close to a million lines of code--we really do need to do a
> better job at modularity if we want to keep growing at this rate.

You can turn any collection of .o and .h into .so with the same .h.
Can't see how that will magically make us think in a more modular
fashion.

But once you have clear interfaces, linking modules separately can help
controlling the cross-module references, and thus help defeating
attempts to bypass the interfaces.

Let's start with step 1.  Earth to Anthony, earth to Anthony, please get
the QOM job done before chasing dynamic modules!  ;-P

> 2) It makes life a bit nicer for distributions as we grow optional
> dependencies. Having a single QEMU binary that links against libtpms
> and libspice means that a distro needs to make libtpms/libspice a
> Requires in the package.  libspice has a ton of dependencies which
> makes QEMU have a ton of hard dependencies. Instead, if a distro can
> build a QEMU package and a qemu-spice package, the libspice dependency
> can be isolated to the qemu-spice package.
>
> That means you can install QEMU on your server without pulling in all
> sorts of ffmpeg stuff if you don't care about Spice.  I'm picking on
> Spice here, but there are lots of other examples here (vde2, libbaum,
> SDL, etc.).
>
> 3) It lets people do out-of-tree development without forking the whole
> tree.  As much as I don't like out-of-tree development, it's a
> reality.  If things like the Android SDK could be done just as a set
> of plugins, it would be better for all of us.

If history is any guide, Google forks everything anyway ;)

> 4) We'll hopefully get to a point where most of what we do can be
> demand loaded. This helps us establish a smaller in memory base which
> is important when it comes to Security Certifications[1].
>
> [1] Security Certification has only an arguable relationship with
> actual security but it is, nonetheless, and important consideration.

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Stefan Hajnoczi]

On Wed, Nov 2, 2011 at 6:51 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> @@ -77,6 +78,20 @@ static DeviceInfo *qdev_find_info(BusInfo *bus_info,
> const ch
>             continue;
>         return info;
>     }
> +
> +    /* try to load an appropriately named module */
> +    {
> +        char *path = g_module_build_path(PREFIX, info->name);
> +        GModule *mod = g_module_open(path, G_MODULE_BIND_LOCAL);
> +        void (*init)(void);
> +
> +        if (g_module_symbol(mod, "mod_init", &init)) {
> +            init();

We need taint marker support from day 1.  Or perhaps a nicer thing:
require each module to declare a support URL string.  QEMU will print
out support URLs when displaying version information or on startup.
This way it's easy to indentify who to ask for help if QEMU appears
broken - we'll know if a third-party plugin is involved.

Stefan

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Markus Armbruster]

Alexander Graf <agraf@suse.de> writes:

> Anthony Liguori wrote:
>> On 11/02/2011 01:17 PM, Jan Kiszka wrote:
>>> On 2011-11-02 18:44, Fabien Chouteau wrote:
>>>> On 31/10/2011 14:12, Peter Maydell wrote:
>>>>> On 29 October 2011 14:52, Alexander Graf<agraf@suse.de>  wrote:
>>>>>> A lot of people seem to also have code that doesn't make sense
>>>>>> upstream, for example implementing a one-off device that only
>>>>>> really matters for their own devboard which nobody else owns.
>>>>>> For such cases, having a plugin framework would be handy. I
>>>>>> interestingly enough got into the same discussion on LinuxCon
>>>>>> with some QEMU downstreams.
>>>>>
>>>>> If we get the qdev rework done then I think we're probably in
>>>>> a better position to have a plugin framework for devices. (There
>>>>> are some issues about API and ABI stability guarantees, of course.)
>>>>>
>>>>
>>>> Interesting, we have a "plug-in" implementation in our Qemu branch. It
>>>
>>> We have a "plugin" model here as well. It's really simple: the plugin is
>>> loaded dynamically into the QEMU process and can access any global
>>> function and variable. Of course, this breaks regularly.
>>
>> Yes, this is the Right Model.
>>
>> All of the work is in making the interfaces not break regularly. 
>> Loading a shared object is easy enough.
>
> I agree. In fact, we could even do it the same way as the kernel and
> build all our internal hw pieces as shared objects.
>
> Then users who want to cut down QEMU can just remove .so files instead
> of messing with the build system or code.

Shared objects have a non-zero cost, both at load time, and at run time.
Whether we can accept that cost just to simplify configuration
management (for a definition of "simplify") isn't obvious.

If removing an optional device model from the build isn't entirely
trivial, we already failed.

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Stefan Hajnoczi]

On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau <chouteau@adacore.com> wrote:
> On 29/10/2011 15:52, Alexander Graf wrote:
>> The RTEMS guys use QEMU to do coverage testing of their kernel code.
>> They run their test-cases and see if all of their code and branches
>> have been hit. Adacore seems to have a patches version of QEMU to
>> provide an easily parsable log file for that sort of thing. Might be a
>> good idea to consolidate upstream. Patches welcome :)
>
> That's right we do have a coverage analysis solution based on Qemu.
> Execution traces generated by Qemu are analyzed by the GNATcoverage
> tool to provide object, statement, decision or Modified
> Condition/Decision coverage analysis.
>
> The main interest of Qemu is to provide execution traces without
> code instrumentation.
>
> Alex, it is of course in our plans to submit patches to the upstream Qemu ;)
>
> I give you some pointers if you want to find more on GNATcoverage (technical stuff :)
>
>  * GNATcoverage is hosted on forge.open-do.org. You can checkout the
>   repository with:
>
>     $ svn checkout svn://scm.forge.open-do.org/scmrepos/svn/couverture/trunk/couverture
>
>   From there, you have
>     * the tool source tree in "tools"
>     * a synthesis article in "publications" : 201005-erts2.pdf
>
>  * GNATcov's documentation attached to this email

Thanks for mentioning Couverture.  Just yesterday I talked to neo_1987
on IRC who is trying to get QEMU /w couverture to work for him.  We
ran into a little bit of confusion because the -trace command-line
option is also used in upstream QEMU but for a different purpose
(http://wiki.qemu.org/Features/Tracing).

I took a quick peak at the qemu-trace.[ch] from couverture and it
looks along the lines of the instrumentation that others have been
doing too.  I hope you have time to propose the coverage
instrumentation for upstream QEMU.

Stefan

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

[...]
> For the record, I'm opposed to ever having a stable plugin API.
>
> We aren't a closed source product.  If people want to have to keep up
> with our changing internal interfaces, they can get their code merged
> upstream.

Seconded.

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Andreas Färber]

Am 03.11.2011 08:46, schrieb Markus Armbruster:
> Anthony Liguori <anthony@codemonkey.ws> writes:
> 
>> For the record, I'm opposed to ever having a stable plugin API.
>>
>> We aren't a closed source product.  If people [don't] want to have to keep up
>> with our changing internal interfaces, they can get their code merged
>> upstream.
> 
> Seconded.

Great. Then let's finally get megasas SCSI merged for 1.1. :)

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Fabien Chouteau]

On 03/11/2011 08:44, Stefan Hajnoczi wrote:
> On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau <chouteau@adacore.com> wrote:
>> On 29/10/2011 15:52, Alexander Graf wrote:
>>> The RTEMS guys use QEMU to do coverage testing of their kernel code.
>>> They run their test-cases and see if all of their code and branches
>>> have been hit. Adacore seems to have a patches version of QEMU to
>>> provide an easily parsable log file for that sort of thing. Might be a
>>> good idea to consolidate upstream. Patches welcome :)
>>
>> That's right we do have a coverage analysis solution based on Qemu.
>> Execution traces generated by Qemu are analyzed by the GNATcoverage
>> tool to provide object, statement, decision or Modified
>> Condition/Decision coverage analysis.
>>
>> The main interest of Qemu is to provide execution traces without
>> code instrumentation.
>>
>> Alex, it is of course in our plans to submit patches to the upstream Qemu ;)
>>
>> I give you some pointers if you want to find more on GNATcoverage (technical stuff :)
>>
>>  * GNATcoverage is hosted on forge.open-do.org. You can checkout the
>>   repository with:
>>
>>     $ svn checkout svn://scm.forge.open-do.org/scmrepos/svn/couverture/trunk/couverture
>>
>>   From there, you have
>>     * the tool source tree in "tools"
>>     * a synthesis article in "publications" : 201005-erts2.pdf
>>
>>  * GNATcov's documentation attached to this email
>
> Thanks for mentioning Couverture.  Just yesterday I talked to neo_1987
> on IRC who is trying to get QEMU /w couverture to work for him.

Great, good to know!

>  We ran into a little bit of confusion because the -trace command-line
>  option is also used in upstream QEMU but for a different purpose
>  (http://wiki.qemu.org/Features/Tracing).
>

We had the same problem, the option is now -exec-trace. Checkout the
qemu-head branch of https://forge.open-do.org/anonscm/git/couverture-qemu/couverture-qemu.git

> I took a quick peak at the qemu-trace.[ch] from couverture and it
> looks along the lines of the instrumentation that others have been
> doing too.  I hope you have time to propose the coverage
> instrumentation for upstream QEMU.
>

I don't know much about other instrumentations in Qemu (pointers are
welcome :), but what we have in couverture-qemu is not trivial,
especially when it comes to MC/DC analysis. You should take a look at
201005-erts2.pdf if you want technical details.

-- 
Fabien Chouteau

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Stefan Hajnoczi]

On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote:
> On 03/11/2011 08:44, Stefan Hajnoczi wrote:
> > On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau <chouteau@adacore.com> wrote:
> >> On 29/10/2011 15:52, Alexander Graf wrote:
> > I took a quick peak at the qemu-trace.[ch] from couverture and it
> > looks along the lines of the instrumentation that others have been
> > doing too.  I hope you have time to propose the coverage
> > instrumentation for upstream QEMU.
> >
> 
> I don't know much about other instrumentations in Qemu (pointers are
> welcome :), but what we have in couverture-qemu is not trivial,
> especially when it comes to MC/DC analysis. You should take a look at
> 201005-erts2.pdf if you want technical details.

My impression was that the QEMU portion of instrumentation was fairly
simple - it writes out trace records at various interesting points
during guest execution in TCG.

I think fancy analysis scripts do not have to be part of QEMU but they
could be added to scripts/ or put in a new contrib/ directory.

On the train, can't access the PDF you mentioned right now.

Stefan

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Fabien Chouteau]

On 04/11/2011 09:36, Stefan Hajnoczi wrote:
> On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote:
>> On 03/11/2011 08:44, Stefan Hajnoczi wrote:
>>> On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>> On 29/10/2011 15:52, Alexander Graf wrote:
>>> I took a quick peak at the qemu-trace.[ch] from couverture and it
>>> looks along the lines of the instrumentation that others have been
>>> doing too.  I hope you have time to propose the coverage
>>> instrumentation for upstream QEMU.
>>>
>>
>> I don't know much about other instrumentations in Qemu (pointers are
>> welcome :), but what we have in couverture-qemu is not trivial,
>> especially when it comes to MC/DC analysis. You should take a look at
>> 201005-erts2.pdf if you want technical details.
> 
> My impression was that the QEMU portion of instrumentation was fairly
> simple - it writes out trace records at various interesting points
> during guest execution in TCG.

It's not rocket science but for MC/DC you have to log history of
branches (taken or not), but if you record everything the output will
unreasonably grow.

>
> I think fancy analysis scripts do not have to be part of QEMU but they
> could be added to scripts/ or put in a new contrib/ directory.

What script are you talking about? GNATcoverage is far more complex than
a fancy script :)

> 
> On the train, can't access the PDF you mentioned right now.

Can't you checkout the repository?

-- 
Fabien Chouteau

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Stefan Hajnoczi]

On Fri, Nov 4, 2011 at 9:53 AM, Fabien Chouteau <chouteau@adacore.com> wrote:
> On 04/11/2011 09:36, Stefan Hajnoczi wrote:
>> On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote:
>>> On 03/11/2011 08:44, Stefan Hajnoczi wrote:
>>>> On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>>> On 29/10/2011 15:52, Alexander Graf wrote:
>>>> I took a quick peak at the qemu-trace.[ch] from couverture and it
>>>> looks along the lines of the instrumentation that others have been
>>>> doing too.  I hope you have time to propose the coverage
>>>> instrumentation for upstream QEMU.
>>>>
>>>
>>> I don't know much about other instrumentations in Qemu (pointers are
>>> welcome :), but what we have in couverture-qemu is not trivial,
>>> especially when it comes to MC/DC analysis. You should take a look at
>>> 201005-erts2.pdf if you want technical details.
>>
>> My impression was that the QEMU portion of instrumentation was fairly
>> simple - it writes out trace records at various interesting points
>> during guest execution in TCG.
>
> It's not rocket science but for MC/DC you have to log history of
> branches (taken or not), but if you record everything the output will
> unreasonably grow.
>
>>
>> I think fancy analysis scripts do not have to be part of QEMU but they
>> could be added to scripts/ or put in a new contrib/ directory.
>
> What script are you talking about? GNATcoverage is far more complex than
> a fancy script :)

I'm not up to speed on GNATcoverage or couverture, so apologies if I'm
wrong - please let me know.  Still, I think we're talking about the
same thing here:

http://www.adacore.com/home/products/gnatpro/add-on_technologies/gnatcoverage/

Looks like GNATemulator is QEMU with additional instrumentation.
GNATcoverage takes the execution traces that the instrumented QEMU
produced.  So when I said "fancy analysis scripts", I meant the tool
that analyzes the trace.

>> On the train, can't access the PDF you mentioned right now.
>
> Can't you checkout the repository?

Sorry, I was reading/replying to mail offline.  I now grabbed the git
repo and looked at commit b82469c906829865693b4fad0edb0a069604a8d9,
which I believe is the main change needed to add couverture tracing to
QEMU.

I'm trying to see if you want to send QEMU changes upstream?

Stefan

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Fabien Chouteau]

On 04/11/2011 13:04, Stefan Hajnoczi wrote:
> On Fri, Nov 4, 2011 at 9:53 AM, Fabien Chouteau <chouteau@adacore.com> wrote:
>> On 04/11/2011 09:36, Stefan Hajnoczi wrote:
>>> On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote:
>>>> On 03/11/2011 08:44, Stefan Hajnoczi wrote:
>>>>> On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>>>> On 29/10/2011 15:52, Alexander Graf wrote:
>>>>> I took a quick peak at the qemu-trace.[ch] from couverture and it
>>>>> looks along the lines of the instrumentation that others have been
>>>>> doing too.  I hope you have time to propose the coverage
>>>>> instrumentation for upstream QEMU.
>>>>>
>>>>
>>>> I don't know much about other instrumentations in Qemu (pointers are
>>>> welcome :), but what we have in couverture-qemu is not trivial,
>>>> especially when it comes to MC/DC analysis. You should take a look at
>>>> 201005-erts2.pdf if you want technical details.
>>>
>>> My impression was that the QEMU portion of instrumentation was fairly
>>> simple - it writes out trace records at various interesting points
>>> during guest execution in TCG.
>>
>> It's not rocket science but for MC/DC you have to log history of
>> branches (taken or not), but if you record everything the output will
>> unreasonably grow.
>>
>>>
>>> I think fancy analysis scripts do not have to be part of QEMU but they
>>> could be added to scripts/ or put in a new contrib/ directory.
>>
>> What script are you talking about? GNATcoverage is far more complex than
>> a fancy script :)
>
> I'm not up to speed on GNATcoverage or couverture, so apologies if I'm
> wrong - please let me know.  Still, I think we're talking about the
> same thing here:
>
> http://www.adacore.com/home/products/gnatpro/add-on_technologies/gnatcoverage/
>
> Looks like GNATemulator is QEMU with additional instrumentation.
> GNATcoverage takes the execution traces that the instrumented QEMU
> produced.  So when I said "fancy analysis scripts", I meant the tool
> that analyzes the trace.
>

In your previous message you seemed to say that GNATcoverage could be
included in Qemu. I just wanted to explain that GNATcoverage is a
project on its own and will not be a part of Qemu.

>>> On the train, can't access the PDF you mentioned right now.
>>
>> Can't you checkout the repository?
>
> Sorry, I was reading/replying to mail offline.  I now grabbed the git
> repo and looked at commit b82469c906829865693b4fad0edb0a069604a8d9,
> which I believe is the main change needed to add couverture tracing to
> QEMU.

Right this is the main commit, there are few others to fix corner cases.

>
> I'm trying to see if you want to send QEMU changes upstream?

As I said it's in our plan, but we don't have time for now. You are
welcome to help if you want to.

-- 
Fabien Chouteau

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Alexander Graf]

On 03.11.2011, at 01:36, Andreas Färber wrote:

> Am 03.11.2011 08:46, schrieb Markus Armbruster:
>> Anthony Liguori <anthony@codemonkey.ws> writes:
>> 
>>> For the record, I'm opposed to ever having a stable plugin API.
>>> 
>>> We aren't a closed source product.  If people [don't] want to have to keep up
>>> with our changing internal interfaces, they can get their code merged
>>> upstream.
>> 
>> Seconded.
> 
> Great. Then let's finally get megasas SCSI merged for 1.1. :)

Yeah, and dictzip which was rejected because "nobody except for us would use it"...


Alex

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Lluís Vilanova]

Stefan Hajnoczi writes:

> On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote:
>> On 03/11/2011 08:44, Stefan Hajnoczi wrote:
>> > On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau <chouteau@adacore.com> wrote:
>> >> On 29/10/2011 15:52, Alexander Graf wrote:
>> > I took a quick peak at the qemu-trace.[ch] from couverture and it
>> > looks along the lines of the instrumentation that others have been
>> > doing too.  I hope you have time to propose the coverage
>> > instrumentation for upstream QEMU.
>> >
>> 
>> I don't know much about other instrumentations in Qemu (pointers are
>> welcome :), but what we have in couverture-qemu is not trivial,
>> especially when it comes to MC/DC analysis. You should take a look at
>> 201005-erts2.pdf if you want technical details.

> My impression was that the QEMU portion of instrumentation was fairly
> simple - it writes out trace records at various interesting points
> during guest execution in TCG.

> I think fancy analysis scripts do not have to be part of QEMU but they
> could be added to scripts/ or put in a new contrib/ directory.

I've only had a brief look into the changes, but I think the mechanism I
implemented has a cleaner fit into QEMU, thanks to previous feedback from this
list.

It explicitly separates the tracing mechanism (in QEMU itself) from the specific
trace analysis (which resides in a separate library specified by the user at
compile time, where most of couverture would go).

On the other hand, I have a complementary set of events, so we can definitely
join the efforts on that side (e.g., I haven't yet went into the trouble of
adding the begin/end TB or branch events).

I have only managed to send the most general changes that are needed before
having the full-fledged instrumentation, but if there's no opposition on having
this kind of feature I will start sending the rest once mainline opens up again
(which I believe won't take much more time).


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Fabien Chouteau]

On 04/11/2011 19:45, Lluís Vilanova wrote:
> Stefan Hajnoczi writes:
> 
>> On Thu, Nov 03, 2011 at 10:35:28AM +0100, Fabien Chouteau wrote:
>>> On 03/11/2011 08:44, Stefan Hajnoczi wrote:
>>>> On Wed, Nov 2, 2011 at 5:39 PM, Fabien Chouteau <chouteau@adacore.com> wrote:
>>>>> On 29/10/2011 15:52, Alexander Graf wrote:
>>>> I took a quick peak at the qemu-trace.[ch] from couverture and it
>>>> looks along the lines of the instrumentation that others have been
>>>> doing too.  I hope you have time to propose the coverage
>>>> instrumentation for upstream QEMU.
>>>>
>>>
>>> I don't know much about other instrumentations in Qemu (pointers are
>>> welcome :), but what we have in couverture-qemu is not trivial,
>>> especially when it comes to MC/DC analysis. You should take a look at
>>> 201005-erts2.pdf if you want technical details.
> 
>> My impression was that the QEMU portion of instrumentation was fairly
>> simple - it writes out trace records at various interesting points
>> during guest execution in TCG.
> 
>> I think fancy analysis scripts do not have to be part of QEMU but they
>> could be added to scripts/ or put in a new contrib/ directory.
> 
> I've only had a brief look into the changes, but I think the mechanism I
> implemented has a cleaner fit into QEMU, thanks to previous feedback from this
> list.

I don't know about your implementation, can you give more information?
What type of analysis is supported (object, statement, decision, MC/DC)?
Which language? And maybe you can post a link to your repository.

>
> It explicitly separates the tracing mechanism (in QEMU itself) from the specific
> trace analysis (which resides in a separate library specified by the user at
> compile time, where most of couverture would go).

As I understand everything is compiled within Qemu, right?

GNATcoverage seems even more separate. We use Qemu to generate an
execution trace file and the coverage analysis tool is a totally
separate program. You can add support for another language or implement
your own coverage tool without recompiling (redistribute) Qemu.

I think that generate a trace file that can be analyzed by any tool is a
better approach for coverage analysis.

>
> On the other hand, I have a complementary set of events, so we can definitely
> join the efforts on that side (e.g., I haven't yet went into the trouble of
> adding the begin/end TB or branch events).

I don't know what do you mean by events, but we sure can join efforts on
coverage with Qemu.

Regards,

-- 
Fabien Chouteau

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Lluís Vilanova]

Fabien Chouteau writes:

> On 04/11/2011 19:45, Lluís Vilanova wrote:
>> I've only had a brief look into the changes, but I think the mechanism I
>> implemented has a cleaner fit into QEMU, thanks to previous feedback from this
>> list.

> I don't know about your implementation, can you give more information?
> What type of analysis is supported (object, statement, decision, MC/DC)?
> Which language? And maybe you can post a link to your repository.

I'll be posting the patches once QEMU opens up for new commits other than
release stabilization. If this is too far away in time, please tell me.


>> It explicitly separates the tracing mechanism (in QEMU itself) from the specific
>> trace analysis (which resides in a separate library specified by the user at
>> compile time, where most of couverture would go).

> As I understand everything is compiled within Qemu, right?

> GNATcoverage seems even more separate. We use Qemu to generate an
> execution trace file and the coverage analysis tool is a totally
> separate program. You can add support for another language or implement
> your own coverage tool without recompiling (redistribute) Qemu.

The process is basically:

* Add trace events that can work during TCG code generation (e.g., start TB,
  start instruction fetch, memory access, etc.)

* Let the user select which trace events to instrument, including both "regular"
  trace events and TCG trace events (thus you instrument at both execution and
  translation time).

* The user provides her own implementation of the instrumented trace events.

As you can see, this system only gives you the hooks were code can be
inserted. Whether your hooks implement everything inside QEMU or just write a
trace file, that is up to you.


[...]
>> 
>> On the other hand, I have a complementary set of events, so we can definitely
>> join the efforts on that side (e.g., I haven't yet went into the trouble of
>> adding the begin/end TB or branch events).

> I don't know what do you mean by events, but we sure can join efforts on
> coverage with Qemu.

Well, my target is not code coverage, but generating events that can be used for
architecture simulation. In any case, there will surely be trace events that
we're both interested in (e.g., TB start and branch).


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Fabien Chouteau]

On 07/11/2011 12:50, Lluís Vilanova wrote:
> Fabien Chouteau writes:
> 
>> On 04/11/2011 19:45, Lluís Vilanova wrote:
>>> I've only had a brief look into the changes, but I think the mechanism I
>>> implemented has a cleaner fit into QEMU, thanks to previous feedback from this
>>> list.
> 
>> I don't know about your implementation, can you give more information?
>> What type of analysis is supported (object, statement, decision, MC/DC)?
>> Which language? And maybe you can post a link to your repository.
> 
> I'll be posting the patches once QEMU opens up for new commits other than
> release stabilization. If this is too far away in time, please tell me.
> 
> 
>>> It explicitly separates the tracing mechanism (in QEMU itself) from the specific
>>> trace analysis (which resides in a separate library specified by the user at
>>> compile time, where most of couverture would go).
> 
>> As I understand everything is compiled within Qemu, right?
> 
>> GNATcoverage seems even more separate. We use Qemu to generate an
>> execution trace file and the coverage analysis tool is a totally
>> separate program. You can add support for another language or implement
>> your own coverage tool without recompiling (redistribute) Qemu.
> 
> The process is basically:
> 
> * Add trace events that can work during TCG code generation (e.g., start TB,
>   start instruction fetch, memory access, etc.)
> 
> * Let the user select which trace events to instrument, including both "regular"
>   trace events and TCG trace events (thus you instrument at both execution and
>   translation time).
> 
> * The user provides her own implementation of the instrumented trace events.
> 
> As you can see, this system only gives you the hooks were code can be
> inserted. Whether your hooks implement everything inside QEMU or just write a
> trace file, that is up to you.
> 

Interesting, what kind of analysis do you plan to perform with this?

> [...]
>>>
>>> On the other hand, I have a complementary set of events, so we can definitely
>>> join the efforts on that side (e.g., I haven't yet went into the trouble of
>>> adding the begin/end TB or branch events).
> 
>> I don't know what do you mean by events, but we sure can join efforts on
>> coverage with Qemu.
> 
> Well, my target is not code coverage, but generating events that can be used for
> architecture simulation. In any case, there will surely be trace events that
> we're both interested in (e.g., TB start and branch).
> 

OK I thought you were talking about coverage. I'm not sure if and how we
can implement coverage using your events but for the moment both
features can cohabit.

-- 
Fabien Chouteau

Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Lluís Vilanova]

Fabien Chouteau writes:
>> The process is basically:
>> 
>> * Add trace events that can work during TCG code generation (e.g., start TB,
>> start instruction fetch, memory access, etc.)
>> 
>> * Let the user select which trace events to instrument, including both "regular"
>> trace events and TCG trace events (thus you instrument at both execution and
>> translation time).
>> 
>> * The user provides her own implementation of the instrumented trace events.
>> 
>> As you can see, this system only gives you the hooks were code can be
>> inserted. Whether your hooks implement everything inside QEMU or just write a
>> trace file, that is up to you.
>> 

> Interesting, what kind of analysis do you plan to perform with this?

Deep full-system or application behaviour analysis, which in my case happens to
be architecture simulation but it could well be data flow tracking, reverse
engineering or anything else.

All users care is about having the right hooks available and being able to plug
in arbitrary code in them.


>> [...]
>>>> 
>>>> On the other hand, I have a complementary set of events, so we can definitely
>>>> join the efforts on that side (e.g., I haven't yet went into the trouble of
>>>> adding the begin/end TB or branch events).
>> 
>>> I don't know what do you mean by events, but we sure can join efforts on
>>> coverage with Qemu.
>> 
>> Well, my target is not code coverage, but generating events that can be used for
>> architecture simulation. In any case, there will surely be trace events that
>> we're both interested in (e.g., TB start and branch).
>> 

> OK I thought you were talking about coverage. I'm not sure if and how we
> can implement coverage using your events but for the moment both
> features can cohabit.

You would just plug in your code in the guest branch instruction and TB
begin/end hooks.


Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth