On Thu, May 12, 2016 at 10:39:00AM +0200, Oswald Buddenhagen wrote:
> On Wed, May 11, 2016 at 09:25:41PM -0400, Damien Riegel wrote:
> > # HG changeset patch
> > # User Damien Riegel <[email protected]>
> > # Date 1462391862 14400
> > #      Wed May 04 15:57:42 2016 -0400
> > # Node ID eb3c1cd64366352abc9f182d7269ac24298533d0
> > # Parent  d18cd04e3f5a07ea6c3d0c0b624c917a0024e037
> > create a dedicated structure for mx operations
> > 
> > This commit introduces a dedicated structure for mailbox operations. The
> > point is to avoid to clobber the context structure with additional
> >
> s/clobber/clutter/
> 
> > callbacks, and to allow each kind of mailboxes to define its own
> > structure.
> >
> you may also want to mention that this structure can be populated
> statically.
> 
> regarding the other patches:
> the series is over-fragmented. 6, 7, and 8 definitely should be
> squashed, as the first two patches make no sense whatsoever without the
> third.

I am used to kernel development, so I like to go from one state to
another through small and atomic changes. To me, it doesn't matter if a
feature takes multiple commits to get implemented as long as the code is
in a working state at every step. Keeping changes as small as possible
makes blame and bisect way more friendly. 

Anyway, this is just what I am used to do. If Kevin wants larger
commits or to squash them when he picks them, that's fine by me.

> the refactorings of the various drivers make sense separately, but
> ideally you'd pull them ahead of 1.
> the mx_ops assigning parts of 8 arguably belong into 1, but i didn't
> look close enough whether that's feasible.

It is a remainer of the first version, which used probe callbacks to
find the right mx_ops to use. Now that it is out, it is probably
possible to do as you're suggesting with a bit of reordering and some
work.

Kevin: just let me know if you want me to do that, or if it is fine as
is.

-- 
Damien

Reply via email to