[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 03/14] tap-solaris: Use error_setg_file_open() for better error messages
- To: "Dr. David Alan Gilbert" <dave@xxxxxxxxxxx>
- From: Markus Armbruster <armbru@xxxxxxxxxx>
- Date: Fri, 21 Nov 2025 06:35:03 +0100
- Cc: qemu-devel@xxxxxxxxxx, arei.gonglei@xxxxxxxxxx, pizhenwei@xxxxxxxxxxxxx, alistair.francis@xxxxxxx, stefanb@xxxxxxxxxxxxxxxxxx, kwolf@xxxxxxxxxx, hreitz@xxxxxxxxxx, sw@xxxxxxxxxxx, qemu_oss@xxxxxxxxxxxxx, groug@xxxxxxxx, mst@xxxxxxxxxx, imammedo@xxxxxxxxxx, anisinha@xxxxxxxxxx, kraxel@xxxxxxxxxx, shentey@xxxxxxxxx, npiggin@xxxxxxxxx, harshpb@xxxxxxxxxxxxx, sstabellini@xxxxxxxxxx, anthony@xxxxxxxxxxxxxx, paul@xxxxxxx, edgar.iglesias@xxxxxxxxx, elena.ufimtseva@xxxxxxxxxx, jag.raman@xxxxxxxxxx, sgarzare@xxxxxxxxxx, pbonzini@xxxxxxxxxx, fam@xxxxxxxxxx, philmd@xxxxxxxxxx, alex@xxxxxxxxxxx, clg@xxxxxxxxxx, peterx@xxxxxxxxxx, farosas@xxxxxxx, lizhijian@xxxxxxxxxxx, jasowang@xxxxxxxxxx, samuel.thibault@xxxxxxxxxxxx, michael.roth@xxxxxxx, kkostiuk@xxxxxxxxxx, zhao1.liu@xxxxxxxxx, mtosatti@xxxxxxxxxx, rathc@xxxxxxxxxxxxx, palmer@xxxxxxxxxxx, liwei1518@xxxxxxxxx, dbarboza@xxxxxxxxxxxxxxxx, zhiwei_liu@xxxxxxxxxxxxxxxxx, marcandre.lureau@xxxxxxxxxx, qemu-block@xxxxxxxxxx, qemu-ppc@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, kvm@xxxxxxxxxxxxxxx, qemu-riscv@xxxxxxxxxx
- Delivery-date: Fri, 21 Nov 2025 05:35:27 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
"Dr. David Alan Gilbert" <dave@xxxxxxxxxxx> writes:
> * Markus Armbruster (armbru@xxxxxxxxxx) wrote:
>> Error messages change from
>>
>> Can't open /dev/ip (actually /dev/udp)
>> Can't open /dev/tap
>> Can't open /dev/tap (2)
>>
>> to
>>
>> Could not open '/dev/udp': REASON
>> Could not open '/dev/tap': REASON
>>
>> where REASON is the value of strerror(errno).
>
> I guess the new macro has a __LINE__ so the (2) is redundant.
It does capture __FILE__, __LINE__, and __func__, but they're only
printed for &error_abort.
How likely is it that the first open of /dev/tap succeeds, and the
second fails?
Do users users then need to know that the second failed? If yes, then
" (2)" is a terrible way to tell them.
>> Signed-off-by: Markus Armbruster <armbru@xxxxxxxxxx>
>
> Reviewed-by: Dr. David Alan Gilbert <dave@xxxxxxxxxxx>
Thanks!
|