[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGG-pUTQgToxUcQkPkE6T9LA2jWvx5DcPq=E_H0XhLJRsPckYQ@mail.gmail.com>
Date: Tue, 29 Oct 2013 18:59:55 -0200
From: Geyslan Gregório Bem <geyslan@...il.com>
To: Eric Van Hensbergen <ericvh@...il.com>
Cc: Joe Perches <joe@...ches.com>, Ron Minnich <rminnich@...dia.gov>,
Latchesar Ionkov <lucho@...kov.net>,
V9FS Developers <v9fs-developer@...ts.sourceforge.net>,
linux-kernel <linux-kernel@...r.kernel.org>,
kernel-br <kernel-br@...glegroups.com>
Subject: Re: [PATCH] 9p: unsigned/signed wrap in p9/unix modes.
2013/10/28 Geyslan Gregório Bem <geyslan@...il.com>:
> 2013/10/28 Geyslan Gregório Bem <geyslan@...il.com>
>>
>> 2013/10/27 Eric Van Hensbergen <ericvh@...il.com>
>>>
>>> Looks like the right approach. The one other optional thing I mentioned was support for passing NULL for rdev and not trying to parse the device info when rdev == NULL. Its a very slight optimization in the grand scheme of things, but would seem to be cleaner for the folks calling the function who don't touch rdev after the fact...
>>>
>>> -eric
>>>
>> Great. Let me do the changes this afternoon.
>>
>>
> Hi Eric and all.
>
> You requested to avoid the parsing of device when rdev is NULL, all
> right? But I'm afraid that that manner the res (return value) can be
> returned wrong when the bit mode is a device. Well, I did some
> changes. In this new approach, when rdev is NULL, the function only
> doesn't make the device, but returns the res (umode_t) nicely.
>
> Tell me if this approach is correct. Do I have to modify something else?
>
> --
> Regards,
>
> Geyslan G. Bem
> hackingbits.com
Eric, I sent the new patch:
[PATCH] 9p: code refactor in vfs_inode.c
--
Regards,
Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists