On Tue, 2010-07-20 at 12:52 +0530, Srikar Dronamraju wrote:
quoted text
> > Just wondering why these are function pointers.  Do we exepect an
> > architecture to provide different versions of these for say 32 vs 64-bit
> > binaries?  If not just making these arch provided helpers might be a lot
> > simpler.  Especially in the current version where only very few of these
> > are overriden by the architecture at all.
> > 
> > > +unsigned long uprobes_read_vm(struct task_struct *tsk, void __user *vaddr,
> > > +                                   void *kbuf, unsigned long nbytes)
> 
> 
> Some of these functions are purely optional example being
> validate_address. 
> 
> Some of these functions need not be defined by the architecture in
> which case we default to the functions defined in common code. 
> examples being: read_opcode, set_bkpt, and set_orig_insn.
> 
> Some of these functions are architecture mode specific, for example 
> there is a architecture specific pre_xol needed for x86_64. However
> generic pre_xol for x86_32 would suffice for x86_32.
> 
> Some of these functions need to be mandatorily defined by the
> architecture. example being set_ip and analyze_insn.
> 
> Apart from the above flexibilities and enforcements that we can make
> when we use function pointers, its would be handy to incorporate
> more enhancements like return probes and booster. 

Still not sure why you're using this vector though, why not use weak
function for optionals and defaults and no implementation for mandatory
functions (and if the implementations fails to provide it, that will
result in a link error).

Are there likely to be multiple different versions of this method vector
around on a running kernel?
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/