KVM Call minutes for 2012-09-25
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".
Quoted 16 lines · 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)
Quoted 3 lines
- 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", ...
Quoted 4 lines
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.
Quoted 18 lines · On Tue, 25 Sep 2012 16:59:00 +0200 Markus Armbruster <[email protected]> wrote:
Quoted 16 lines · 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)
Quoted 6 lines
Quoted 3 lines
- how to give errors from OpenFile to the caller putting errno as int: bad idea
putting as strerrno string: also a bad idea, no waranteesUse 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.
Quoted 25 lines · Luiz Capitulino
Quoted 22 lines · On Tue, 25 Sep 2012 16:59:00 +0200 Markus Armbruster <[email protected]> wrote:
Quoted 19 lines · 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
Quoted 5 lines
Quoted 2 lines
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