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