----- Original Message ----- > From: "Sam Ravnborg" <sam@xxxxxxxxxxxx> > To: "Andrew Stiegmann" <astiegmann@xxxxxxxxxx> > Cc: linux-kernel@xxxxxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, pv-drivers@xxxxxxxxxx, > vm-crosstalk@xxxxxxxxxx, cschamp@xxxxxxxxxx, gregkh@xxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
