[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-kernel
Subject:    [RFC PATCH 2/2] ARM: kprobes: Add 32-bit Thumb instruction decoding and simulation
From:       nicolas.pitre () linaro ! org (Nicolas Pitre)
Date:       2011-06-28 17:37:34
Message-ID: alpine.LFD.2.00.1106281327430.2142 () xanadu ! home
[Download RAW message or body]

On Tue, 28 Jun 2011, Tixy wrote:

> When preparing kprobe patches for review and submission, at what sort of
> granularity is it useful to break them down into? E.g. this patch
> currently has 6 simulation functions, 6 emulation functions and about 12
> decode tables. I could do:
> 
> a. one big patch

Definitely not a good idea, unless you wish to be ignored.

> b. 3 patches, one each for simulation functions, emulation functions,
>    and decode tables
> 
> c. 24 patches, one for each function / table.
> 
> d. more like I wrote it, a patch for each table and include the
>    functions as they first get used in the tables.
> 
> e. even more like I wrote it, a patch for each instruction form as it is
>    added (40+ patches?)
> 
> It's not clear to me which of these makes it easier to review, or worth
> the effort, Any advice?

I would say that d is probably the most natural.  This way each patch on 
its own is a logical addition, and added pieces are used right away.

BTW, unless you already split those patches, a good way to go about 
doing it is to:

1) start a new branch with the whole thing already committed and 
   working;

2) start _removing_ features one by one and commit each of those 
   removals, making sure that the code still compiles;

3) then generate a patch series from that branch in the reverse order.


Nicolas


[prev in list] [next in list] [prev in thread] [next in thread]