----- Original Message ----- > From: "Sam Ravnborg" <s...@ravnborg.org> > To: "Andrew Stiegmann" <astiegm...@vmware.com> > Cc: linux-ker...@vger.kernel.org, virtualization@lists.linux-foundation.org, > pv-driv...@vmware.com, > vm-crosst...@vmware.com, csch...@vmware.com, gre...@linuxfoundation.org > Sent: Friday, July 27, 2012 12:53:20 PM > Subject: Re: [vmw_vmci 11/11] Apply the header code to make VMCI build > > > > > + > > > > +#define CAN_BLOCK(_f) (!((_f) & VMCI_QPFLAG_NONBLOCK)) > > > > +#define QP_PINNED(_f) ((_f) & VMCI_QPFLAG_PINNED) > > > > > > Looks like poor obscufation. > > > Use a statis inline function if you need a helper for this. > > > > These definitions are intended more as a helper to make reading the > > code easier. IMHO ts a lot easier to read > > > > if (CAN_BLOCK(flags)) > > > > compared to > > > > if (!(flags & VMCI_QPFLAG_NONBLOCK)) > > > > Wouldn't you agree? I'm not sure something this simple warrants a > > static inline > > function but I don't see any harm in converting it over to that. > > I would put it the other way around. I cannot see that such simple > stuff warrants a #define. > A static inline is (almost) always preferable to hide code in a > macro. > > For once you get better type-checks. > And semantics are also much simpler. With a macro you can do so many > silly things.
Fair enough. I'll make them into static inline functions. > Sam > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
