[Xenomai-core] [PATCH] uClibc compile failure

[Xenomai-core] [PATCH] uClibc compile failure

[Fillod Stephane]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

Hi,

I have bumped on a compilation failure of Xenomai 2.4.6 with uClibc.
The mmap64/ftruncate64 functions may not be available, at all.
So here's an attached patch against 2.4.6, FWIW.

BTW, people stuck with a fascist pthread that lets only superuser use 
SCHED_FIFO will need the following patch. Same discussion[1] applies.
[1] https://mail.gna.org/public/xenomai-help/2007-05/msg00330.html

--- src/skins/native/task.c     9 Jun 2008 09:38:14 -0000       1.5
+++ src/skins/native/task.c     8 Dec 2008 10:37:55 -0000
@@ -139,7 +139,13 @@

        pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
        memset(&param, 0, sizeof(param));
-       if (prio > 0) {
+       /* There's a limitation in libpthread
+        * that returns EPERM upon SCHED_FIFO
+        * for non priviledged users.
+        * So workaround this for now.
+        * FIXME (in uClibc/pthread).
+        */
+       if (prio > 0 && geteuid() == 0) {
                pthread_attr_setschedpolicy(&thattr, SCHED_FIFO);
                param.sched_priority = prio;
        } else

-- 
Stephane

[-- Attachment #2: xeno-uclibc-link.patch --]
[-- Type: application/octet-stream, Size: 1105 bytes --]

--- configure.in	17 Nov 2008 10:47:09 -0000	1.9
+++ configure.in	8 Dec 2008 10:11:56 -0000
@@ -733,7 +733,7 @@
 
 save_LIBS="$LIBS"
 LIBS="$LIBS -lrt"
-AC_CHECK_FUNCS([shm_open shm_unlink])
+AC_CHECK_FUNCS([shm_open shm_unlink mmap64 ftruncate64])
 LIBS="$save_LIBS"
 
 dnl
--- src/skins/posix/shm.c	17 Nov 2008 10:47:20 -0000	1.3
+++ src/skins/posix/shm.c	8 Dec 2008 10:11:56 -0000
@@ -160,8 +160,10 @@
 	if (!err)
 		return 0;
 
+#ifdef HAVE_FTRUNCATE64
 	if (err == EBADF || err == ENOSYS)
 		return __real_ftruncate64(fildes, length);
+#endif
 
 	errno = err;
 	return -1;
@@ -185,8 +187,10 @@
 				 ((unsigned long long) off < LONG_MAX
 				  ? (long) off : -1L), &map);
 
+#ifdef HAVE_MMAP64
 	if (err == EBADF || err == ENOSYS)
 		return __real_mmap64(addr, len, prot, flags, fildes, off);
+#endif
 
 	if (err)
 		goto error;
@@ -196,8 +200,12 @@
 	if (err)
 		goto err_mmap_epilogue;
 
+#ifdef HAVE_MMAP64
 	/* map the whole heap. */
 	uaddr = __real_mmap64(NULL, map.mapsize, prot, flags, fildes, 0);
+#else
+	uaddr = MAP_FAILED;
+#endif
 
 	if (uaddr == MAP_FAILED) {
 	      err_mmap_epilogue:

Re: [Xenomai-core] [PATCH] uClibc compile failure

[Fillod Stephane]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

Hi,

I haven't seen a reply to this patch, maybe it has been missed?

https://mail.gna.org/public/xenomai-core/2008-12/msg00009.html


---8<-------8<-------8<-------8<-------8<-------8<----

I have bumped on a compilation failure of Xenomai 2.4.6 with uClibc.
The mmap64/ftruncate64 functions may not be available, at all.
So here's an attached patch (xeno-uclibc-link.patch) against 2.4.6,
FWIW.

BTW, people stuck with a fascist pthread that lets only superuser use 
SCHED_FIFO will also need the following patch. Same discussion[1]
applies.
[1] https://mail.gna.org/public/xenomai-help/2007-05/msg00330.html

--- src/skins/native/task.c     9 Jun 2008 09:38:14 -0000       1.5
+++ src/skins/native/task.c     8 Dec 2008 10:37:55 -0000
@@ -139,7 +139,13 @@

        pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
        memset(&param, 0, sizeof(param));
-       if (prio > 0) {
+       /* There's a limitation in libpthread
+        * that returns EPERM upon SCHED_FIFO
+        * for non priviledged users.
+        * So workaround this for now.
+        * FIXME (in uClibc/pthread).
+        */
+       if (prio > 0 && geteuid() == 0) {
                pthread_attr_setschedpolicy(&thattr, SCHED_FIFO);
                param.sched_priority = prio;
        } else

-- 
Stephane

[-- Attachment #2: xeno-uclibc-link.patch --]
[-- Type: application/octet-stream, Size: 1105 bytes --]

--- configure.in	17 Nov 2008 10:47:09 -0000	1.9
+++ configure.in	8 Dec 2008 10:11:56 -0000
@@ -733,7 +733,7 @@
 
 save_LIBS="$LIBS"
 LIBS="$LIBS -lrt"
-AC_CHECK_FUNCS([shm_open shm_unlink])
+AC_CHECK_FUNCS([shm_open shm_unlink mmap64 ftruncate64])
 LIBS="$save_LIBS"
 
 dnl
--- src/skins/posix/shm.c	17 Nov 2008 10:47:20 -0000	1.3
+++ src/skins/posix/shm.c	8 Dec 2008 10:11:56 -0000
@@ -160,8 +160,10 @@
 	if (!err)
 		return 0;
 
+#ifdef HAVE_FTRUNCATE64
 	if (err == EBADF || err == ENOSYS)
 		return __real_ftruncate64(fildes, length);
+#endif
 
 	errno = err;
 	return -1;
@@ -185,8 +187,10 @@
 				 ((unsigned long long) off < LONG_MAX
 				  ? (long) off : -1L), &map);
 
+#ifdef HAVE_MMAP64
 	if (err == EBADF || err == ENOSYS)
 		return __real_mmap64(addr, len, prot, flags, fildes, off);
+#endif
 
 	if (err)
 		goto error;
@@ -196,8 +200,12 @@
 	if (err)
 		goto err_mmap_epilogue;
 
+#ifdef HAVE_MMAP64
 	/* map the whole heap. */
 	uaddr = __real_mmap64(NULL, map.mapsize, prot, flags, fildes, 0);
+#else
+	uaddr = MAP_FAILED;
+#endif
 
 	if (uaddr == MAP_FAILED) {
 	      err_mmap_epilogue:

Re: [Xenomai-core] [PATCH] uClibc compile failure

[Philippe Gerum]

Fillod Stephane wrote:
> Hi,
> 
> I haven't seen a reply to this patch, maybe it has been missed?
>

Actually, it was on queue but delayed by the inlined patch.
The shm_open/unlink should be fixed by now in both the v2.4.x and trunk
branches, I stumbled over them as well while hacking on Blackfin a few weeks
ago; please confirm.

My concern with the inlined patch is basically that it looks like papering over
the problem, but the task will not run in the SCHED_FIFO class anyway, because
it will fail again in the trampoline. However, we do need that task to run in
the SCHED_FIFO class for a number of internal reasons. Could you confirm that
behavior on your target?

TIA,

> https://mail.gna.org/public/xenomai-core/2008-12/msg00009.html
> 
> 
> ---8<-------8<-------8<-------8<-------8<-------8<----
> 
> I have bumped on a compilation failure of Xenomai 2.4.6 with uClibc.
> The mmap64/ftruncate64 functions may not be available, at all.
> So here's an attached patch (xeno-uclibc-link.patch) against 2.4.6,
> FWIW.
> 
> BTW, people stuck with a fascist pthread that lets only superuser use 
> SCHED_FIFO will also need the following patch. Same discussion[1]
> applies.
> [1] https://mail.gna.org/public/xenomai-help/2007-05/msg00330.html
> 
> --- src/skins/native/task.c     9 Jun 2008 09:38:14 -0000       1.5
> +++ src/skins/native/task.c     8 Dec 2008 10:37:55 -0000
> @@ -139,7 +139,13 @@
> 
>         pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
>         memset(&param, 0, sizeof(param));
> -       if (prio > 0) {
> +       /* There's a limitation in libpthread
> +        * that returns EPERM upon SCHED_FIFO
> +        * for non priviledged users.
> +        * So workaround this for now.
> +        * FIXME (in uClibc/pthread).
> +        */
> +       if (prio > 0 && geteuid() == 0) {
>                 pthread_attr_setschedpolicy(&thattr, SCHED_FIFO);
>                 param.sched_priority = prio;
>         } else
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 
Philippe.

Re: [Xenomai-core] [PATCH] uClibc compile failure

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> Fillod Stephane wrote:
>> Hi,
>>
>> I haven't seen a reply to this patch, maybe it has been missed?
>>
> 
> Actually, it was on queue but delayed by the inlined patch.
> The shm_open/unlink should be fixed by now in both the v2.4.x and trunk

You mean mmap64/ftruncate64, right?

-- 
                                                 Gilles.

Re: [Xenomai-core] [PATCH] uClibc compile failure

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Fillod Stephane wrote:
>>> Hi,
>>>
>>> I haven't seen a reply to this patch, maybe it has been missed?
>>>
>> Actually, it was on queue but delayed by the inlined patch.
>> The shm_open/unlink should be fixed by now in both the v2.4.x and trunk
> 
> You mean mmap64/ftruncate64, right?
> 

No, errno=-ENOBRAIN. I just answered a question that was not asked, confusing
both issues. I will merge that part then.

-- 
Philippe.