Re: [PATCH 02/05] Linux Kernel Markers, architecture independant code.

Mathieu Desnoyers <[email protected]>
Newsgroups gmane.linux.systemtap,gmane.linux.kernel,gmane.linux.kernel.tracing
Message-ID <20070215191222.GB31359@Krystal>
* Andrew Morton ([email protected]) wrote:
> On Sun, 11 Feb 2007 15:03:24 -0500 Mathieu Desnoyers <[email protected]> wrote:
> 
> > Linux Kernel Markers, architecture independant code.
> > 
> > Signed-off-by: Mathieu Desnoyers <[email protected]>
> > 
> > ...
> >
> > +
> > +#ifndef MARK
> > +#define MARK GEN_MARK
> > +#define MARK_ENABLE_TYPE GEN_MARK_ENABLE_TYPE
> > +#define MARK_ENABLE_IMMEDIATE_OFFSET GEN_MARK_ENABLE_IMMEDIATE_OFFSET
> > +#endif
> 
> Also perhaps this nastiness can go away once each architecture has
> asm/marker.h?
> 
Yes, absolutely.

> > +#ifdef MARK_POLYMORPHIC
> 
> What's this?  Is it commented somewhere?  (It should be...)
> 

No, but should be : it is defined by the architecture's marker.h when
the marker flavor has to do code motification when the marker state is
modified.


> > +static int marker_set_ins_enable(void *address, char enable)
> > +{
> > +#ifdef CONFIG_X86_32
> > +	return arch_marker_set_ins_enable(address, enable);
> > +#else
> > +	char newi[MARK_ENABLE_IMMEDIATE_OFFSET+1];
> > +	int size = MARK_ENABLE_IMMEDIATE_OFFSET+sizeof(MARK_ENABLE_TYPE);
> > +
> > +	memcpy(newi, address, size);
> > +	MARK_ENABLE(&newi[0]) = enable;
> > +	memcpy(address, newi, size);
> > +	flush_icache_range((unsigned long)address, size);
> > +	return 0;
> > +#endif //CONFIG_X86_32
> > +}
> 
> eww.  Can we put a suitable arch_marker_set_ins_enable() into each arch's
> marker.h?
> 

Or maybe put that in asm-generic so we do not duplicate code.

> > +#else
> > +static int marker_set_ins_enable(void *address, char enable)
> > +{
> > +	return -EPERM;
> > +}
> > +#endif //MARK_POLYMORPHIC
> > +
> >
> > ...
> >
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, École Polytechnique de Montréal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.