Re: [RFC PATCH 1/5] new helper: iov_iter_rw()
On Tue, Mar 17, 2015 at 10:31:51AM +0100, David Sterba wrote:
On Mon, Mar 16, 2015 at 05:36:05PM +, Al Viro wrote:
On Mon, Mar 16, 2015 at 04:33:49AM -0700, Omar Sandoval wrote:
Get either READ or WRITE out of iter-type.
Umm...
+ * Get one of READ or WRITE out of iter-type without any other flags
OR'd in
+ * with it.
+ */
+static inline int iov_iter_rw(const struct iov_iter *i)
+{
+ return i-type RW_MASK;
+}
TBH, I would turn that into a macro. Reason: indirect includes.
Agreed, but the proposed define is rather cryptic and I was not able to
understand the meaning on the first glance.
#define iov_iter_rw(i) ((0 ? (struct iov_iter *)0 : (i))-type RW_MASK)
This worked for me, does not compile with anything else than
'struct iov_iter*' as i:
#define iov_iter_rw(i)({ \
struct iov_iter __iter = *(i); \
(i)-type RW_MASK;\
})
The assignment is optimized out.
[-cc individual fs maintainers to avoid all of these email bounces,
should've looked a bit closer at that get_maintainer.pl output...]
I agree that this is a bit more readable, but it evaluates i twice.
That's an easy fix, just do __iter.type instead of (i)-type, but
there's still the possibility of someone passing in something called
__iter as i, and the fix for that tends to be add more underscores. At
the very least, Al's macro could probably use a comment explaining
what's going on there, though.
--
Omar
--
To unsubscribe from this list: send the line unsubscribe linux-cifs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] new helper: iov_iter_rw()
On Mon, Mar 16, 2015 at 05:36:05PM +, Al Viro wrote:
On Mon, Mar 16, 2015 at 04:33:49AM -0700, Omar Sandoval wrote:
Get either READ or WRITE out of iter-type.
Umm...
+ * Get one of READ or WRITE out of iter-type without any other flags OR'd
in
+ * with it.
+ */
+static inline int iov_iter_rw(const struct iov_iter *i)
+{
+ return i-type RW_MASK;
+}
TBH, I would turn that into a macro. Reason: indirect includes.
Agreed, but the proposed define is rather cryptic and I was not able to
understand the meaning on the first glance.
#define iov_iter_rw(i) ((0 ? (struct iov_iter *)0 : (i))-type RW_MASK)
This worked for me, does not compile with anything else than
'struct iov_iter*' as i:
#define iov_iter_rw(i) ({ \
struct iov_iter __iter = *(i); \
(i)-type RW_MASK;\
})
The assignment is optimized out.
--
To unsubscribe from this list: send the line unsubscribe linux-cifs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] new helper: iov_iter_rw()
On Tue, Mar 17, 2015 at 10:31:51AM +0100, David Sterba wrote:
Agreed, but the proposed define is rather cryptic and I was not able to
understand the meaning on the first glance.
#define iov_iter_rw(i) ((0 ? (struct iov_iter *)0 : (i))-type RW_MASK)
This worked for me, does not compile with anything else than
'struct iov_iter*' as i:
#define iov_iter_rw(i)({ \
struct iov_iter __iter = *(i); \
(i)-type RW_MASK;\
})
The assignment is optimized out.
... and you are getting
a) use of rather lousy gccism when plain C would do
b) double evaluation since you've got it wrong (should've been
__iter.type RW_MASK, if you do it that way). As it is, if argument has
any side effects, your variant will trigger those twice - even if the
destination of the assignment is never used, the side effects remain.
I agree that it could use /* use ?: for typechecking */, but let's not go into
({...}) land unless we absolutely have to.
--
To unsubscribe from this list: send the line unsubscribe linux-cifs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] new helper: iov_iter_rw()
On Mon, Mar 16, 2015 at 04:33:49AM -0700, Omar Sandoval wrote:
Get either READ or WRITE out of iter-type.
Umm...
+ * Get one of READ or WRITE out of iter-type without any other flags OR'd in
+ * with it.
+ */
+static inline int iov_iter_rw(const struct iov_iter *i)
+{
+ return i-type RW_MASK;
+}
TBH, I would turn that into a macro. Reason: indirect includes.
How about
#define iov_iter_rw(i) ((0 ? (struct iov_iter *)0 : (i))-type RW_MASK)
Should do you all the type safety of inline function and avoids the need
to include fs.h in uio.h; _users_ of iov_iter_rw() obviously still need
fs.h, but such places always used to...
--
To unsubscribe from this list: send the line unsubscribe linux-cifs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
