[Qemu-devel] KVM Call minutes for 2012-09-25

[Qemu-devel] KVM Call minutes for 2012-09-25

[Juan Quintela]

Hi

This are this week minutes:

- URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
same code. (Paolo)
 * code hasn't changed in 2 years, it is really stable
 * anthony wants to copy the code

- there are several commands that do blocking IO
  dump-guest-memory/screen-dump
  convert to asynchronous commands after we move all to QAPI
  only two commands missingto port to QAPI, and one is posted on list
  non-blocking IO to a file is a challenge
  (we have code on the block layer for it)

- how to give errors from OpenFile to the caller
  putting errno as int: bad idea
  putting as strerrno string: also a bad idea, no warantees
  Using an extended error code
  Put it as a string that can be parsed?
  Paolo suggest to create a new error class
  We don't warantee that errors would be "parseable".

Re: [Qemu-devel] KVM Call minutes for 2012-09-25

[Markus Armbruster]

Juan Quintela <quintela@redhat.com> writes:

> Hi
>
> This are this week minutes:
>
> - URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
> same code. (Paolo)
>  * code hasn't changed in 2 years, it is really stable
>  * anthony wants to copy the code
>
> - there are several commands that do blocking IO
>   dump-guest-memory/screen-dump
>   convert to asynchronous commands after we move all to QAPI
>   only two commands missingto port to QAPI, and one is posted on list
>   non-blocking IO to a file is a challenge
>   (we have code on the block layer for it)
>
> - how to give errors from OpenFile to the caller
>   putting errno as int: bad idea
>   putting as strerrno string: also a bad idea, no warantees

Use the identifiers instead of their non-portable numeric encodings or
strerror() descriptions: "EPERM", "EINVAL", ...

>   Using an extended error code
>   Put it as a string that can be parsed?
>   Paolo suggest to create a new error class
>   We don't warantee that errors would be "parseable".

We don't want programs to parse the human-readable error string.

Re: [Qemu-devel] KVM Call minutes for 2012-09-25

[Luiz Capitulino]

On Tue, 25 Sep 2012 16:59:00 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Juan Quintela <quintela@redhat.com> writes:
> 
> > Hi
> >
> > This are this week minutes:
> >
> > - URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
> > same code. (Paolo)
> >  * code hasn't changed in 2 years, it is really stable
> >  * anthony wants to copy the code
> >
> > - there are several commands that do blocking IO
> >   dump-guest-memory/screen-dump
> >   convert to asynchronous commands after we move all to QAPI
> >   only two commands missingto port to QAPI, and one is posted on list
> >   non-blocking IO to a file is a challenge
> >   (we have code on the block layer for it)
> >
> > - how to give errors from OpenFile to the caller
> >   putting errno as int: bad idea
> >   putting as strerrno string: also a bad idea, no warantees
> 
> Use the identifiers instead of their non-portable numeric encodings or
> strerror() descriptions: "EPERM", "EINVAL", ...

Yes, but for me the important point in this discussion is whether
or not a new class is necessary. I think it it isn't.

Re: [Qemu-devel] KVM Call minutes for 2012-09-25

[Anthony Liguori]

Luiz Capitulino <lcapitulino@redhat.com> writes:

> On Tue, 25 Sep 2012 16:59:00 +0200
> Markus Armbruster <armbru@redhat.com> wrote:
>
>> Juan Quintela <quintela@redhat.com> writes:
>> 
>> > Hi
>> >
>> > This are this week minutes:
>> >
>> > - URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
>> > same code. (Paolo)
>> >  * code hasn't changed in 2 years, it is really stable
>> >  * anthony wants to copy the code
>> >
>> > - there are several commands that do blocking IO
>> >   dump-guest-memory/screen-dump
>> >   convert to asynchronous commands after we move all to QAPI
>> >   only two commands missingto port to QAPI, and one is posted on list
>> >   non-blocking IO to a file is a challenge
>> >   (we have code on the block layer for it)
>> >
>> > - how to give errors from OpenFile to the caller
>> >   putting errno as int: bad idea
>> >   putting as strerrno string: also a bad idea, no warantees
>> 
>> Use the identifiers instead of their non-portable numeric encodings or
>> strerror() descriptions: "EPERM", "EINVAL", ...
>
> Yes, but for me the important point in this discussion is whether
> or not a new class is necessary. I think it it isn't.

If we have a tool that needs to differientiate errors, chances are
another user needs to also.

Regards,

Anthony Liguori