[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH V3 13/22] Add evtchn_abi_str
On Wed, Feb 27, 2013 at 04:51:45PM +0000, Jan Beulich wrote: > >>> On 27.02.13 at 15:34, Wei Liu <wei.liu2@xxxxxxxxxx> wrote: > > --- a/xen/common/event_channel.c > > +++ b/xen/common/event_channel.c > > @@ -36,6 +36,20 @@ > > uint32_t extended_event_channel = (EVTCHN_EXTENDED_NONE | > > EVTCHN_EXTENDED_L3); > > > > +static inline const char * evtchn_abi_str(unsigned int abi) > > +{ > > + switch ( abi ) > > + { > > + case EVTCHN_EXTENDED_NONE: > > + return "2-level"; > > + case EVTCHN_EXTENDED_L3: > > + return "3-level"; > > + default: > > + BUG(); > > + } > > + return ""; /* make compiler happy */ > > +} > > + > > This is the sort of change that looks completely bogus - even the > next few patches don't seem to make use of this. Why can't this > be added when the first user of it appears? It surely won't make > reviewing that patch more difficult... > Do you mean the implementation is bogus or the way I break my patches? > And that's a general problem (for me at least) with how you break > up patches: Having looked ahead at 18 and 19, the latter undoes > quite a significant portion of what the former did. Both being far > from huge and unreviewable, why don't you fold them so things > actually make sense to the reader? > Sure, this can be done. Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |