[3/3] trace-cmd: Use PyLong_AsLong() for Python 3

Commit Message

Steven Rostedt July 19, 2019, 10:46 p.m. UTC

From: "Steven Rostedt (VMware)" <[e-mail]>

Python 3 has deprecated PyInt_AS_LONG. Add code to use PyLong_AsLong() if
Python 3 is detected. As Python 2 is going to be EOL soon, we need to
support Python 3.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204231

Reported-by: Troy Engel <[e-mail]>
Signed-off-by: Steven Rostedt (VMware) <[e-mail]>
---
 python/ctracecmd.i | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

Comments

Johannes Berg July 26, 2019, 7:31 a.m. UTC | #1

On Fri, 2019-07-19 at 18:46 -0400, Steven Rostedt wrote:
 
> +#if PY_MAJOR_VERSION >= 3
[...]
> +#define PY_INT_AS_LONG PyLong_AsLong
>  #else
[...]
> +#define PY_INT_AS_LONG PyInt_AS_LONG
> +#endif

I probably would've gone for only having a single

 #define PyLong_AsLong PyInt_AS_LONG

in the python2 case, but doesn't really matter.


Reviewed-by: Johannes Berg <[e-mail]>

johannes

Steven Rostedt July 26, 2019, 3:18 p.m. UTC | #2

On Fri, 26 Jul 2019 09:31:57 +0200
Johannes Berg <[e-mail]> wrote:

> On Fri, 2019-07-19 at 18:46 -0400, Steven Rostedt wrote:
>  
> > +#if PY_MAJOR_VERSION >= 3  
> [...]
> > +#define PY_INT_AS_LONG PyLong_AsLong
> >  #else  
> [...]
> > +#define PY_INT_AS_LONG PyInt_AS_LONG
> > +#endif  
> 
> I probably would've gone for only having a single
> 
>  #define PyLong_AsLong PyInt_AS_LONG
> 
> in the python2 case, but doesn't really matter.
> 
> 
> Reviewed-by: Johannes Berg <[e-mail]>
> 

Hi Johannes,

Thanks for the review (unfortunately, due to the rush to get
KernelShark 1.0 out, I already applied them, I should have Cc'd you on
them too).

Should we make any of the above changes you mentioned to any of these
patches? I'm looking at releasing trace-cmd 2.8.4 with all these
changes and will hold off if you think it would be better to update
them.

Thanks!

-- Steve

Johannes Berg July 26, 2019, 3:22 p.m. UTC | #3

Hi,

> Thanks for the review (unfortunately, due to the rush to get
> KernelShark 1.0 out, I already applied them, I should have Cc'd you on
> them too).

> 
> Should we make any of the above changes you mentioned to any of these
> patches? I'm looking at releasing trace-cmd 2.8.4 with all these
> changes and will hold off if you think it would be better to update
> them.

I don't think it matters.

The PyLong thing was just really cosmetic, could've saved some lines of
code.

The bytes vs. unicode - well, python assumes that you give it a utf-8
string, so even if we start using non-ASCII identifiers (which I think
is highly unlikely!), we'll likely use utf-8 in the kernel, and it would
either way not be an issue.

johannes

Steven Rostedt July 26, 2019, 3:30 p.m. UTC | #4

On Fri, 26 Jul 2019 17:22:58 +0200
Johannes Berg <[e-mail]> wrote:


> The bytes vs. unicode - well, python assumes that you give it a utf-8
> string, so even if we start using non-ASCII identifiers (which I think
> is highly unlikely!), we'll likely use utf-8 in the kernel, and it would
> either way not be an issue.

Thanks Johannes for explaining.

-- Steve

Patch

diff --git a/python/ctracecmd.i b/python/ctracecmd.i
index 63e5dcb813f1..2601d39a76be 100644
--- a/python/ctracecmd.i
+++ b/python/ctracecmd.i
@@ -117,14 +117,21 @@  static PyObject *py_field_get_stack(struct tep_handle *pevent,
 	return list;
 }
 
+#if PY_MAJOR_VERSION >= 3
 static PyObject *fromMemory(void *buf, size_t len)
 {
-#if PY_MAJOR_VERSION >= 3
 		return PyMemoryView_FromMemory(buf, len, PyBUF_READ);
+}
+#define PY_INT_AS_LONG PyLong_AsLong
 #else
+static PyObject *fromMemory(void *buf, size_t len)
+{
 		return PyBuffer_FromMemory(buf, len);
-#endif
 }
+#define PY_INT_AS_LONG PyInt_AS_LONG
+#endif
+
+
 
 static PyObject *py_field_get_data(struct tep_format_field *f, struct tep_record *r)
 {
@@ -226,7 +233,7 @@  static int python_callback(struct trace_seq *s,
 			Py_XDECREF(result);
 			return 0;
 		}
-		r = PyInt_AS_LONG(result);
+		r = PY_INT_AS_LONG(result);
 	} else if (result == Py_None)
 		r = 0;
 	else