On 27/09/2024 02.51, jro...@linux.ibm.com wrote:
From: Jared Rossi <jro...@linux.ibm.com>Remove panic-on-error from ECKD block device IPL specific functions so that error recovery may be possible in the future. Functions that would previously panic now provide a return code. Signed-off-by: Jared Rossi <jro...@linux.ibm.com> --- pc-bios/s390-ccw/bootmap.c | 183 +++++++++++++++++++++++++------------ 1 file changed, 125 insertions(+), 58 deletions(-) diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c index 0751a225cd..dc7200c264 100644 --- a/pc-bios/s390-ccw/bootmap.c +++ b/pc-bios/s390-ccw/bootmap.c @@ -145,14 +145,17 @@ static block_number_t load_eckd_segments(block_number_t blk, bool ldipl, bool more_data;memset(_bprs, FREE_SPACE_FILLER, sizeof(_bprs));- read_block(blk, bprs, "BPRS read failed"); + if (virtio_read(blk, bprs)) { + puts("BPRS read failed"); + return -EIO; + }do {more_data = false; for (j = 0;; j++) { block_nr = gen_eckd_block_num(&bprs[j].xeckd, ldipl); if (is_null_block_number(block_nr)) { /* end of chunk */ - break; + return 0; /* use 0 to indicate end of load, not real block 0 */
Can we be very sure that block 0 is never a valid one, so that returning 0 is OK here? Maybe you could use an error code instead (intruducing e.g. ENOENT ?)
Thomas
