Messages in this thread | | | Date | Sun, 21 Oct 2012 20:43:30 +0200 | From | Rabin Vincent <> | Subject | Re: [PATCH 9/9] ARM: add uprobes support |
| |
On Wed, Oct 17, 2012 at 03:50:48PM +0100, Jon Medhurst (Tixy) wrote: > I just been looking at the decoding changes in patch 8 and had similar > thoughts. The patch as it stands looks rather bolted on the side and > makes the resulting code rather messy.
I agree.
> a) uprobes is similar enough to kprobes that the existing code can be > morphed into something that cleanly supports both, or > > b) the similarities aren't close enough and that we should factor out > the similarities into a more generalised decoding base, which the > {u,k}probe code can then build on. > > c) some mix of a) and b) > > I can't help but think of the various calls over the past year or so for > a general ARM/Thumb instruction decoding framework (the last one only a > few weeks ago on the linux-arm-kernel list). Perhaps b) would be a small > step towards that. > > I hope to find some time to understand the uprobe patches in more > detail, so I can try and come up with some sensible suggestions on a > cleaner solution; because I feel that as they stand they aren't really > suitable for inclusion in the kernel.
I contemplated sending the decoding patch with [RFC] but finally went with [PATCH] since they mostly mean the same thing :-).
Suggestions welcome. For one thing, the creation of a fake struct kprobe from within the uprobes and the dependency on kprobes because of that is not very nice, we probably need a "struct probe" of some sort perhaps.
> Rabin, what tree/commit are your patches based on? (They don't seem to > apply cleanly to 3.6 or 3.7-rc1.) I want to apply them locally so I can > use my favourite visualisation tool and to play with them.
The patches are based on next-20121012. The uprobes core is seeing quite a few changes in linux-next so the series will probably not apply on later linux-next trees.
| |