On 13/10/25 14:05, Peter Maydell wrote:
On Mon, 13 Oct 2025 at 08:02, Vishal Chourasia <[email protected]> wrote:
On Tue, Oct 07, 2025 at 02:29:52PM +0100, Peter Maydell wrote:
On Tue, 7 Oct 2025 at 13:59, Vishal Chourasia <[email protected]> wrote:
<...snip...>
Rather than printing a list of reasons why the load might
have failed, I think it would be better if we enhanced
the error handling in load_image_targphys() and friends
(i.e. use Error), so that these functions can report back
to the caller exactly why they failed and then the caller
can give that error message to the user. That way we can
improve the error reporting for every board that uses
these load functions.
Hello Peter,
Wouldn't it be better to print the error inside the function itself.
No, because some users of this family of load functions
use a sequence of calls to handle different possible
formats. We don't want the function to load file format A
to print any errors if we're then going to continue and
successfully load the file as format B.
More generally, our usual coding practice for functions
is that they use Error to tell the caller what went wrong,
and it's the caller that then gets to decide whether they
want to print an error and exit, tell the monitor about
an error, or just continue to try something else instead.
In that case, maybe we can have 'load_image_targphys' take an 'enum
LoadError*' ? Caller can pass that argument if interesting in handling
errors.
Though i see 71 instances of this function, will have to modify all call
sites (probably by passing NULL as error* which will be same as previous
usage).
What do you say ?
Thanks,
- Aditya G
-- PMM
