On Wed, Aug 07, 2024 at 09:37:00AM +0200, Philippe Mathieu-Daudé wrote:
> On 6/8/24 17:20, Daniel P. Berrangé wrote:
> > On Tue, Aug 06, 2024 at 05:11:55PM +0200, Philippe Mathieu-Daudé wrote:
> > > On 6/8/24 16:56, Daniel P. Berrangé wrote:
> > > > The eBPF code is currently reporting error messag
On 7/8/24 09:37, Philippe Mathieu-Daudé wrote:
On 6/8/24 17:20, Daniel P. Berrangé wrote:
On Tue, Aug 06, 2024 at 05:11:55PM +0200, Philippe Mathieu-Daudé wrote:
On 6/8/24 16:56, Daniel P. Berrangé wrote:
The eBPF code is currently reporting error messages through trace
events. Trace events ar
On 6/8/24 17:20, Daniel P. Berrangé wrote:
On Tue, Aug 06, 2024 at 05:11:55PM +0200, Philippe Mathieu-Daudé wrote:
On 6/8/24 16:56, Daniel P. Berrangé wrote:
The eBPF code is currently reporting error messages through trace
events. Trace events are fine for debugging, but they are not to be
con
On Tue, Aug 06, 2024 at 05:11:55PM +0200, Philippe Mathieu-Daudé wrote:
> On 6/8/24 16:56, Daniel P. Berrangé wrote:
> > The eBPF code is currently reporting error messages through trace
> > events. Trace events are fine for debugging, but they are not to be
> > considered the primary error reporti
On 6/8/24 16:56, Daniel P. Berrangé wrote:
The eBPF code is currently reporting error messages through trace
events. Trace events are fine for debugging, but they are not to be
considered the primary error reporting mechanism, as their output
is inaccessible to callers.
This adds an "Error **err
The eBPF code is currently reporting error messages through trace
events. Trace events are fine for debugging, but they are not to be
considered the primary error reporting mechanism, as their output
is inaccessible to callers.
This adds an "Error **errp" parameter to all methods which have
import
