On Tue, 5 Jul 2011, Tixy wrote:
On Tue, 2011-07-05 at 11:38 -0400, Nicolas Pitre wrote:
On Tue, 5 Jul 2011, Tixy wrote:
Irrespective of correct interworking behaviour and API issues, do we think that it's a good memory saving exercise to not support probing ARM code on Thumb kernels?
I would think so. And if this is really something people need then this could be revisited in the future. Remember that you gain no points by trying to submit everything on a zero-day.
There isn't really much lines of code or diffstat saving not supporting ARM code on Thumb kernels. In fact, for cleanness reasons I would need to reorganise code. Currently we have
kprobes.c Infrastructure kprobes-decode.c ARM instruction decoding and simulation
My changes at the moment have
kprobes.c Infrastructure (700 lines) kprobes-decode.c ARM instruction decoding and simulation (1000 lines) Common instruction decoding and simulation (400 lines) Decoding table processing (300 lines) kprobes-thumb.c Thumb instruction decoding and simulation (1500 lines)
To avoid #ifdef the ARM instruction decoding should be in its own file and not built for Thumb kernels. So the minimal change would be to move
Common instruction decoding and simulation Decoding table processing
into kprobes.c, or probably nicer into a new kprobes-common.c. (We could then rename kprobes-decode to kprobes-arm and have things looking neat.)
As this is reworking 70 patches, I would like confirmation that the approach is good before starting ;-)
Sure, looks sensible. Better do the renaming first and only add new stuff to it with subsequent patches.
Keeping the kprobes interface separate from the actual table and simulation/emulation handling is certainly a good idea too. So you'd end up with kprobes.c, kprobes-common.c, kprobes-arm.c and kprobles-thumb.c.
Nicolas