qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] 9pfs-proxy: simplify error handling


From: Aneesh Kumar K.V
Subject: Re: [Qemu-devel] [PATCH 1/3] 9pfs-proxy: simplify error handling
Date: Sun, 08 Mar 2015 21:57:11 +0530
User-agent: Notmuch/0.19+30~gd241a48 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)

Michael Tokarev <address@hidden> writes:

> 07.03.2015 23:37, Eric Blake wrote:
>> On 03/06/2015 02:43 PM, Michael Tokarev wrote:
>>> All filesystem methods that call common v9fs_request() function
>>> also convert return value to errno.  Move this conversion to the
>>> common function and remove redundand error handling in methods.
>> 
>> s/redundand/redundant/
>
> Heh.  Is this all that I can say about this patch? ;)
>
> Actually, after reading almost whole 9pfs and fsdev code, I can
> say with great confidence this code is nearly hopeless.

Is that about the 9pfs-proxy code, or the rest of 9pfs. I understand
that the error handling can definitely get some cleanup. I mentioned
that in my previous mail
mail. http://mid.gmane.org/address@hidden


> Patch 3 shows just one (huge) example.  There are so many issues
> with this code, I'm afraid I don't have know the words to express
> it.
>
> Again, patch 3 shows a good example.  Another example:
>
> static int v9fs_receive_status(V9fsProxy *proxy,
>                                struct iovec *reply, int *status)
> ...
>     proxy_unmarshal(reply, 0, "dd", &header.type, &header.size);
>     if (header.size != sizeof(int)) {
>         *status = -ENOBUFS;
>     }
> ...
>     proxy_unmarshal(reply, PROXY_HDR_SZ, "d", status);
>
> proxy_unmarshall(), for "d" element, expects an int32_t
> pointer.  Here we have int pointer, and compare its
> size with sizeof(int).  This is a generic problem of whole
> v9fs_(un)marshall interface, which is in the core of 9pfs...
> this is a status return, which is int32.
>
> Oh well.  I've no idea how this code has been accepted.
> It is absolute crap.
>

-aneesh




reply via email to

[Prev in Thread] Current Thread [Next in Thread]