On 9/21/22 16:03, Claudio Fontana wrote:
On 9/21/22 14:16, Markus Armbruster wrote:
Philippe Mathieu-Daudé writes:
On 16/9/22 11:27, Markus Armbruster wrote:
Claudio Fontana writes:
improve error handling during module load, by changing:
bool module_load_one(const char *prefix, const cha
On 9/22/22 19:05, Kevin Wolf wrote:
> Am 22.09.2022 um 17:27 hat Markus Armbruster geschrieben:
>> Kevin Wolf writes:
>>
>>> Am 22.09.2022 um 14:42 hat Markus Armbruster geschrieben:
>>
>> [...]
>>
If you have callers that need to distinguish between not found, found
but bad, found and g
On 9/23/22 07:31, Markus Armbruster wrote:
> Claudio Fontana writes:
>
>> On 9/22/22 16:36, Markus Armbruster wrote:
>>> Claudio Fontana writes:
>>>
On 9/22/22 15:20, Markus Armbruster wrote:
> Claudio Fontana writes:
>
> [...]
>
>> I think it would be better to complet
On 9/22/22 19:05, Kevin Wolf wrote:
> Am 22.09.2022 um 17:27 hat Markus Armbruster geschrieben:
>> Kevin Wolf writes:
>>
>>> Am 22.09.2022 um 14:42 hat Markus Armbruster geschrieben:
>>
>> [...]
>>
If you have callers that need to distinguish between not found, found
but bad, found and g
Claudio Fontana writes:
> On 9/22/22 16:36, Markus Armbruster wrote:
>> Claudio Fontana writes:
>>
>>> On 9/22/22 15:20, Markus Armbruster wrote:
Claudio Fontana writes:
[...]
> I think it would be better to completely make the return value separate
> from the Erro
Am 22.09.2022 um 17:27 hat Markus Armbruster geschrieben:
> Kevin Wolf writes:
>
> > Am 22.09.2022 um 14:42 hat Markus Armbruster geschrieben:
>
> [...]
>
> >> If you have callers that need to distinguish between not found, found
> >> but bad, found and good, then return three distinct values.
On 9/22/22 17:27, Markus Armbruster wrote:
> Kevin Wolf writes:
>
>> Am 22.09.2022 um 14:42 hat Markus Armbruster geschrieben:
>
> [...]
>
>>> If you have callers that need to distinguish between not found, found
>>> but bad, found and good, then return three distinct values.
>>>
>>> I proposed
Kevin Wolf writes:
> Am 22.09.2022 um 14:42 hat Markus Armbruster geschrieben:
[...]
>> If you have callers that need to distinguish between not found, found
>> but bad, found and good, then return three distinct values.
>>
>> I proposed to return -1 for found but bad (error), 0 for not found
On 9/22/22 16:36, Markus Armbruster wrote:
> Claudio Fontana writes:
>
>> On 9/22/22 15:20, Markus Armbruster wrote:
>>> Claudio Fontana writes:
>>>
>>> [...]
>>>
I think it would be better to completely make the return value separate
from the Error,
and really treat Error as an
Claudio Fontana writes:
> On 9/22/22 15:20, Markus Armbruster wrote:
>> Claudio Fontana writes:
>>
>> [...]
>>
>>> I think it would be better to completely make the return value separate
>>> from the Error,
>>> and really treat Error as an exception and not mix it up with the regular
>>> exe
On 9/22/22 16:54, Kevin Wolf wrote:
> Am 22.09.2022 um 14:42 hat Markus Armbruster geschrieben:
>> Claudio Fontana writes:
>>
>>> On 9/22/22 11:38, Markus Armbruster wrote:
Daniel P. Berrangé writes:
> On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
>> Ease of
Am 22.09.2022 um 14:42 hat Markus Armbruster geschrieben:
> Claudio Fontana writes:
>
> > On 9/22/22 11:38, Markus Armbruster wrote:
> >> Daniel P. Berrangé writes:
> >>
> >>> On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
> Ease of use matters, too. When sticking to t
On Thu, Sep 22, 2022 at 03:34:42PM +0200, Philippe Mathieu-Daudé wrote:
> On Thu, Sep 22, 2022 at 3:20 PM Markus Armbruster wrote:
> >
> > Claudio Fontana writes:
> >
> > [...]
> >
> > > I think it would be better to completely make the return value separate
> > > from the Error,
> > > and reall
On 9/22/22 15:44, Daniel P. Berrangé wrote:
> On Thu, Sep 22, 2022 at 03:34:42PM +0200, Philippe Mathieu-Daudé wrote:
>> On Thu, Sep 22, 2022 at 3:20 PM Markus Armbruster wrote:
>>>
>>> Claudio Fontana writes:
>>>
>>> [...]
>>>
I think it would be better to completely make the return value s
On 9/22/22 15:34, Philippe Mathieu-Daudé wrote:
> On Thu, Sep 22, 2022 at 3:20 PM Markus Armbruster wrote:
>>
>> Claudio Fontana writes:
>>
>> [...]
>>
>>> I think it would be better to completely make the return value separate
>>> from the Error,
>>> and really treat Error as an exception and n
On Thu, Sep 22, 2022 at 3:20 PM Markus Armbruster wrote:
>
> Claudio Fontana writes:
>
> [...]
>
> > I think it would be better to completely make the return value separate
> > from the Error,
> > and really treat Error as an exception and not mix it up with the regular
> > execution,
> >
> > b
On Thu, Sep 22, 2022 at 02:30:35PM +0200, Claudio Fontana wrote:
> On 9/22/22 12:37, Daniel P. Berrangé wrote:
> > On Thu, Sep 22, 2022 at 11:34:22AM +0200, Claudio Fontana wrote:
> >> On 9/22/22 11:31, Daniel P. Berrangé wrote:
> >>> On Thu, Sep 22, 2022 at 11:20:07AM +0200, Claudio Fontana wrote:
On 9/22/22 15:20, Markus Armbruster wrote:
> Claudio Fontana writes:
>
> [...]
>
>> I think it would be better to completely make the return value separate from
>> the Error,
>> and really treat Error as an exception and not mix it up with the regular
>> execution,
>>
>> but if it is the gener
Claudio Fontana writes:
[...]
> I think it would be better to completely make the return value separate from
> the Error,
> and really treat Error as an exception and not mix it up with the regular
> execution,
>
> but if it is the general consensus that I am the only one seeing this
> confla
On 9/22/22 12:37, Daniel P. Berrangé wrote:
> On Thu, Sep 22, 2022 at 11:34:22AM +0200, Claudio Fontana wrote:
>> On 9/22/22 11:31, Daniel P. Berrangé wrote:
>>> On Thu, Sep 22, 2022 at 11:20:07AM +0200, Claudio Fontana wrote:
On 9/22/22 10:28, Daniel P. Berrangé wrote:
>
>> Another in
On 9/22/22 14:42, Markus Armbruster wrote:
> Claudio Fontana writes:
>
>> On 9/22/22 11:38, Markus Armbruster wrote:
>>> Daniel P. Berrangé writes:
>>>
On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
> Ease of use matters, too. When sticking to the rule leads to awkw
Claudio Fontana writes:
> On 9/22/22 11:38, Markus Armbruster wrote:
>> Daniel P. Berrangé writes:
>>
>>> On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
Ease of use matters, too. When sticking to the rule leads to awkward
code, we should stop and think. Should we
On 9/22/22 14:33, Daniel P. Berrangé wrote:
> On Thu, Sep 22, 2022 at 02:30:35PM +0200, Claudio Fontana wrote:
>> On 9/22/22 12:37, Daniel P. Berrangé wrote:
>>> On Thu, Sep 22, 2022 at 11:34:22AM +0200, Claudio Fontana wrote:
On 9/22/22 11:31, Daniel P. Berrangé wrote:
> On Thu, Sep 22, 2
Daniel P. Berrangé writes:
> On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
>> Ease of use matters, too. When sticking to the rule leads to awkward
>> code, we should stop and think. Should we deviate from the rule? Or
>> can we avoid that by tweaking the interface?
>>
>>
On Thu, Sep 22, 2022 at 11:34:22AM +0200, Claudio Fontana wrote:
> On 9/22/22 11:31, Daniel P. Berrangé wrote:
> > On Thu, Sep 22, 2022 at 11:20:07AM +0200, Claudio Fontana wrote:
> >> On 9/22/22 10:28, Daniel P. Berrangé wrote:
> >>>
> Another interface that does: return -1 for error, 0 for m
On 9/22/22 11:21, Claudio Fontana wrote:
> On 9/22/22 11:20, Claudio Fontana wrote:
>> On 9/22/22 10:28, Daniel P. Berrangé wrote:
>>> On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
Ease of use matters, too. When sticking to the rule leads to awkward
code, we should s
On Thu, Sep 22, 2022 at 11:20:07AM +0200, Claudio Fontana wrote:
> On 9/22/22 10:28, Daniel P. Berrangé wrote:
> >
> >> Another interface that does: return -1 for error, 0 for module not found
> >> (no error), and 1 for loaded.
> >
> > IMHO this pattern is generally easier to understand when look
On 9/22/22 11:20, Claudio Fontana wrote:
> On 9/22/22 10:28, Daniel P. Berrangé wrote:
>> On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
>>> Ease of use matters, too. When sticking to the rule leads to awkward
>>> code, we should stop and think. Should we deviate from the rule
On 9/22/22 10:28, Daniel P. Berrangé wrote:
> On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
>> Ease of use matters, too. When sticking to the rule leads to awkward
>> code, we should stop and think. Should we deviate from the rule? Or
>> can we avoid that by tweaking the int
On 9/22/22 11:38, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
>> On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
>>> Ease of use matters, too. When sticking to the rule leads to awkward
>>> code, we should stop and think. Should we deviate from the rule? Or
>>> c
On 9/22/22 11:31, Daniel P. Berrangé wrote:
> On Thu, Sep 22, 2022 at 11:20:07AM +0200, Claudio Fontana wrote:
>> On 9/22/22 10:28, Daniel P. Berrangé wrote:
>>>
Another interface that does: return -1 for error, 0 for module not found
(no error), and 1 for loaded.
>>>
>>> IMHO this patter
On Thu, Sep 22, 2022 at 08:07:43AM +0200, Markus Armbruster wrote:
> Ease of use matters, too. When sticking to the rule leads to awkward
> code, we should stop and think. Should we deviate from the rule? Or
> can we avoid that by tweaking the interface?
>
> Philippe's proposed interface sticks
Claudio Fontana writes:
> On 9/21/22 14:16, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé writes:
>>
>>> On 16/9/22 11:27, Markus Armbruster wrote:
Claudio Fontana writes:
> improve error handling during module load, by changing:
>
> bool module_load_one(const char *
On 9/21/22 14:16, Markus Armbruster wrote:
> Philippe Mathieu-Daudé writes:
>
>> On 16/9/22 11:27, Markus Armbruster wrote:
>>> Claudio Fontana writes:
>>>
improve error handling during module load, by changing:
bool module_load_one(const char *prefix, const char *lib_name);
Claudio Fontana writes:
> Hi Markus, sorry for the harsh response last week, it comes from a position
> of lack of time,
> and the expectation that Richard's review would be enough.
I gladly accept your apology.
We had the good fortune to meet in person (at KVM Forums before the
plague). Make
Philippe Mathieu-Daudé writes:
> On 16/9/22 11:27, Markus Armbruster wrote:
>> Claudio Fontana writes:
>>
>>> improve error handling during module load, by changing:
>>>
>>> bool module_load_one(const char *prefix, const char *lib_name);
>>> void module_load_qom_one(const char *type);
>>>
>>> t
On 16/9/22 11:27, Markus Armbruster wrote:
Claudio Fontana writes:
improve error handling during module load, by changing:
bool module_load_one(const char *prefix, const char *lib_name);
void module_load_qom_one(const char *type);
to:
bool module_load_one(const char *prefix, const char *nam
On 9/19/22 10:17, Markus Armbruster wrote:
> Claudio Fontana writes:
>
>> On 9/16/22 16:26, Markus Armbruster wrote:
>>> Claudio Fontana writes:
>>>
On 9/16/22 11:27, Markus Armbruster wrote:
> Claudio Fontana writes:
>
> [...]
>
>> diff --git a/block.c b/block.c
>> index bc8
Claudio Fontana writes:
> On 9/16/22 16:26, Markus Armbruster wrote:
>> Claudio Fontana writes:
>>
>>> On 9/16/22 11:27, Markus Armbruster wrote:
Claudio Fontana writes:
[...]
> diff --git a/block.c b/block.c
> index bc85f46eed..8b610c6d95 100644
> --- a/block.c
> +++ b/
On 9/16/22 16:26, Markus Armbruster wrote:
> Claudio Fontana writes:
>
>> On 9/16/22 11:27, Markus Armbruster wrote:
>>> Claudio Fontana writes:
>>>
improve error handling during module load, by changing:
bool module_load_one(const char *prefix, const char *lib_name);
void mo
Claudio Fontana writes:
> On 9/16/22 11:27, Markus Armbruster wrote:
>> Claudio Fontana writes:
>>
>>> improve error handling during module load, by changing:
>>>
>>> bool module_load_one(const char *prefix, const char *lib_name);
>>> void module_load_qom_one(const char *type);
>>>
>>> to:
>>>
On 9/16/22 11:27, Markus Armbruster wrote:
> Claudio Fontana writes:
>
>> improve error handling during module load, by changing:
>>
>> bool module_load_one(const char *prefix, const char *lib_name);
>> void module_load_qom_one(const char *type);
>>
>> to:
>>
>> bool module_load_one(const char *p
Claudio Fontana writes:
> improve error handling during module load, by changing:
>
> bool module_load_one(const char *prefix, const char *lib_name);
> void module_load_qom_one(const char *type);
>
> to:
>
> bool module_load_one(const char *prefix, const char *name, Error **errp);
> bool module_l
On 9/16/22 10:13, Richard Henderson wrote:
> On 9/8/22 20:30, Claudio Fontana wrote:
>> improve error handling during module load, by changing:
>>
>> bool module_load_one(const char *prefix, const char *lib_name);
>> void module_load_qom_one(const char *type);
>>
>> to:
>>
>> bool module_load_one(c
On 9/8/22 20:30, Claudio Fontana wrote:
improve error handling during module load, by changing:
bool module_load_one(const char *prefix, const char *lib_name);
void module_load_qom_one(const char *type);
to:
bool module_load_one(const char *prefix, const char *name, Error **errp);
bool module_
On 9/8/22 20:30, Claudio Fontana wrote:
> improve error handling during module load, by changing:
>
> bool module_load_one(const char *prefix, const char *lib_name);
> void module_load_qom_one(const char *type);
>
> to:
>
> bool module_load_one(const char *prefix, const char *name, Error **errp)
improve error handling during module load, by changing:
bool module_load_one(const char *prefix, const char *lib_name);
void module_load_qom_one(const char *type);
to:
bool module_load_one(const char *prefix, const char *name, Error **errp);
bool module_load_qom_one(const char *type, Error **err
47 matches
Mail list logo
