On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote:
> On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote:
> > On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote:
> > > On Wednesday 23 June 2010 02:41 pm, Xin LI wrote:
> > > > On 2010/06/23 11:37, Jung-uk Kim wrote:
> > > > > On Wednesday 23 June 2010 02:12 pm, Xin LI wrote:
> > > > >> Hi,
> > > > >>
> > > > >> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote:
> > > > >>> Hi,
> > > > >>>
> > > > >>> I am getting more than 4 thousand of the following
> > > > >>> messages a day:
> > > > >>>
> > > > >>> WARNING pid 24509 (python2.6): ioctl sign-extension ioctl
> > > > >>> ffffffff8004667e
> > > > >>
> > > > >> [...]
> > > > >>
> > > > >> I think we may need to check the code and patch it.
> > > > >> Basically this means that python (or some .so modules)
> > > > >> passed an int or unsigned int as parameter 'cmd', we need
> > > > >> to change it to unsigned long.
> > > > >>
> > > > >> The warning itself should be harmless to my best of
> > > > >> knowledge, one can probably remove the printf in kernel
> > > > >> source code as a workaround.
> > > > >>
> > > > >> By the way it seems to be a POSIX violation and we didn't
> > > > >> seem to really use so wide cmd, but I have not yet
> > > > >> verified everything myself.
> > > > >
> > > > > Long time ago, I had a similar problem with termios
> > > > > TIOCGWINSZ and we patched the port like this:
> > > > >
> > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/fil
> > > > >es /A tt
> > > > > ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=te
> > > > >xt %2 Fpl ain
> > > > >
> > > > > I believe it was upstream patched at the time but I won't
> > > > > be surprised if something similar was reintroduced. It
> > > > > happens when a Python internal integer type is converted to
> > > > > a native unsigned long.
> > > >
> > > > Well, only *BSD have cmd a long value so it's likely that it
> > > > would be reintroduced.
> > >
> > > Yes, that's what I mean.
> > >
> > > > I have checked the 4.4BSD archive and understood that our
> > > > ioctl's cmd parameter was made long around 1991 or 1992s but
> > > > didn't see what it actually buy us...
> > >
> > > Like it or not, it is too late to revert. :-(
> >
> > From Python 2.6.5:
> >
> > static PyObject *
> > fcntl_ioctl(PyObject *self, PyObject *args)
> > {
> > #define IOCTL_BUFSZ 1024
> > int fd;
> > /* In PyArg_ParseTuple below, we use the unsigned non-checked
> > 'I' format for the 'code' parameter because Python turns
> > 0x8000000 into either a large positive number (PyLong or PyInt on
> > 64-bit platforms) or a negative number on others (32-bit PyInt)
> > whereas the system expects it to be a 32bit bit field value
> > regardless of it being passed as an int or unsigned long on
> > various platforms. See the termios.TIOCSWINSZ constant across
> > platforms for an example of thise.
> >
> > If any of the 64bit platforms ever decide to use more than
> > 32bits in their unsigned long ioctl codes this will break and
> > need special casing based on the platform being built on.
> > */
> > unsigned int code;
> > ...
> >
> > It is still a kludge and it won't be fixed. :-(
>
> Please drop the attached patch in ports/lang/python26/files and
> test. Note I am not a Python guy, so please don't shoot me. ;-)
I found that Python guys added 'k' format since 2.3, which converts a
Python integer to unsigned long. Please ignore the previous patch
and try the attached patch instead.
Cheers,
Jung-uk Kim
--- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.000000000 -0400
+++ Modules/fcntlmodule.c 2010-06-23 16:56:10.000000000 -0400
@@ -97,6 +97,13 @@
{
#define IOCTL_BUFSZ 1024
int fd;
+#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \
+ defined(__OpenBSD__)
+#define IOCTL_ULONG 1
+#endif
+#ifdef IOCTL_ULONG
+ unsigned long code;
+#else
/* In PyArg_ParseTuple below, we use the unsigned non-checked 'I'
format for the 'code' parameter because Python turns 0x8000000
into either a large positive number (PyLong or PyInt on 64-bit
@@ -105,12 +112,9 @@
regardless of it being passed as an int or unsigned long on
various platforms. See the termios.TIOCSWINSZ constant across
platforms for an example of thise.
-
- If any of the 64bit platforms ever decide to use more than 32bits
- in their unsigned long ioctl codes this will break and need
- special casing based on the platform being built on.
*/
unsigned int code;
+#endif
int arg;
int ret;
char *str;
@@ -118,7 +122,11 @@
int mutate_arg = 1;
char buf[IOCTL_BUFSZ+1]; /* argument plus NUL byte */
+#ifdef IOCTL_ULONG
+ if (PyArg_ParseTuple(args, "O&kw#|i:ioctl",
+#else
if (PyArg_ParseTuple(args, "O&Iw#|i:ioctl",
+#endif
conv_descriptor, &fd, &code,
&str, &len, &mutate_arg)) {
char *arg;
@@ -169,7 +177,11 @@
}
PyErr_Clear();
+#ifdef IOCTL_ULONG
+ if (PyArg_ParseTuple(args, "O&ks#:ioctl",
+#else
if (PyArg_ParseTuple(args, "O&Is#:ioctl",
+#endif
conv_descriptor, &fd, &code, &str, &len)) {
if (len > IOCTL_BUFSZ) {
PyErr_SetString(PyExc_ValueError,
@@ -191,7 +203,11 @@
PyErr_Clear();
arg = 0;
if (!PyArg_ParseTuple(args,
+#ifdef IOCTL_ULONG
+ "O&k|i;ioctl requires a file or file descriptor,"
+#else
"O&I|i;ioctl requires a file or file descriptor,"
+#endif
" an integer and optionally an integer or buffer argument",
conv_descriptor, &fd, &code, &arg)) {
return NULL;
@@ -209,6 +225,7 @@
}
return PyInt_FromLong((long)ret);
#undef IOCTL_BUFSZ
+#undef IOCTL_ULONG
}
PyDoc_STRVAR(ioctl_doc,
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
