Re: Debian packages for Xenomai 3.x
El 6/11/18 a les 19:04, Jan Kiszka ha escrit: > On 30.11.17 12:27, Leopold Palomo-Avellaneda wrote: >> Hi, >> >> >> if someone is interested I have been working a bit with the debian directory >> in >> xenomai3. >> >> I have changed the approach to the libraries. I think that now it has not >> sense >> to have a libxenomai1 so I have changed it to xenomai3-libs. >> >> The source, and the patches applied are here: >> >> https://anonscm.debian.org/cgit/collab-maint/xenomai.git/ >> >> In case there's some interest, I can try to push it again to the official >> Debian >> repositories. >> > > Picking up this topic again: > > I'm also in favor of reanimating the upstream Debian package, provided it adds > value to users. In the past, a downside was the unhandy kernel build process, > but maybe users were still happy. OTH, we may have a chance to provide > binaries > at least for the standard target x86-64. > > I'm currently preparing Debian-based demo and test images, generated > automatically via some "magic" (Isar image builder). For that, we will need > clean debian control files also in the Xenomai repo. That raises the question > how to keep both debian folders best in sync - if both should be used. > Suggestions? Debian repos contain several branches and one of them is upstream that doesn't contain any reference to Debian. So, maybe you could create a branch, with a snapshot of the development where you work with the debian directory. Something similar as Debian does. Then, you could create another one with the Debian official or simply we could drop the Debian official and change for this one. In any case, I agree that this should be reanimating. I proposed some renaming of the packages but they didn't have too much interest, but I'm quite interested to have it active. Best regards, Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia - A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://xenomai.org/pipermail/xenomai/attachments/20181108/748e62e9/attachment.sig>
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 11/8/18 2:15 PM, Jan Kiszka wrote: > On 08.11.18 14:09, Philippe Gerum wrote: >> On 11/8/18 2:05 PM, Philippe Gerum via Xenomai wrote: >>> On 11/5/18 1:20 PM, Jan Kiszka wrote: The mayday mechanism exists in order to kick a xenomai userspace task into secondary mode while it is running userspace code. For that, we ask I-pipe to call us back when the task was interrupted and is about to return to userspace. So far we defer the relaxation from that callback via a VDSO-like mechanism that triggers a special syscall to the return path of that very same syscall. However, that is not desirable because it is a complex, arch-specific mechanism that can easily break and, specifically, that destroys the backtrace of ptraced tasks. Fortunately, we can fulfill the needs of mayday also by relaxing the task directly from the mayday callback. Tested successfully on x86-64 and ARM. >>> >>> ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work >>> properly. This method would cause an interrupt state breakage with any >>> older ARM patch. >>> >> >> ppc32 is fine back to kernel 4.1 regarding this (did not check earlier >> stuff), and arm64 needs the 4.14-based split series to work properly >> (4.9 is wrong). > > Is the reason for arm64 on 4.9 the same as for arm? > Yes, same pattern. -- Philippe.
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 08.11.18 14:05, Philippe Gerum wrote: On 11/5/18 1:20 PM, Jan Kiszka wrote: The mayday mechanism exists in order to kick a xenomai userspace task into secondary mode while it is running userspace code. For that, we ask I-pipe to call us back when the task was interrupted and is about to return to userspace. So far we defer the relaxation from that callback via a VDSO-like mechanism that triggers a special syscall to the return path of that very same syscall. However, that is not desirable because it is a complex, arch-specific mechanism that can easily break and, specifically, that destroys the backtrace of ptraced tasks. Fortunately, we can fulfill the needs of mayday also by relaxing the task directly from the mayday callback. Tested successfully on x86-64 and ARM. ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work properly. This method would cause an interrupt state breakage with any older ARM patch. That would be a change compared to my past ARM experiments (4.x, if not 3.x based). Can you point me to the problem in more details? Thanks, Jan
Re: [PATCH] cobalt/kernel: Simplify mayday processing
On 11/8/18 2:05 PM, Philippe Gerum via Xenomai wrote: > On 11/5/18 1:20 PM, Jan Kiszka wrote: >> The mayday mechanism exists in order to kick a xenomai userspace task >> into secondary mode while it is running userspace code. For that, we ask >> I-pipe to call us back when the task was interrupted and is about to >> return to userspace. >> >> So far we defer the relaxation from that callback via a VDSO-like >> mechanism that triggers a special syscall to the return path of that >> very same syscall. However, that is not desirable because it is a >> complex, arch-specific mechanism that can easily break and, >> specifically, that destroys the backtrace of ptraced tasks. >> >> Fortunately, we can fulfill the needs of mayday also by relaxing >> the task directly from the mayday callback. Tested successfully on >> x86-64 and ARM. > > ARM-wise, this change requires ipipe-core-4.14.71-arm-3 or later to work > properly. This method would cause an interrupt state breakage with any > older ARM patch. > ppc32 is fine back to kernel 4.1 regarding this (did not check earlier stuff), and arm64 needs the 4.14-based split series to work properly (4.9 is wrong). -- Philippe.
[PATCH] testsuite/xeno-test: do not swallow exit status anymore
xeno-test-run always returned SUCCESS, even if its children exited with
non zero. So xeno-test can not be used programmatically i.e. in CI.
This patch adds some more verbosity and makes xeno-test-run exit FAILURE
if at least one child returned non-zero.
Signed-off-by: Henning Schild
---
testsuite/xeno-test/xeno-test-run.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/testsuite/xeno-test/xeno-test-run.c
b/testsuite/xeno-test/xeno-test-run.c
index bfede63fd..6d1bb96c0 100644
--- a/testsuite/xeno-test/xeno-test-run.c
+++ b/testsuite/xeno-test/xeno-test-run.c
@@ -51,6 +51,8 @@ void handle_checked_child(struct child *child, fd_set *fds);
void handle_script_child(struct child *child, fd_set *fds);
void handle_load_child(struct child *child, fd_set *fds);
+static int exit_global = EXIT_SUCCESS;
+
static inline time_t mono_time(void)
{
struct timespec ts;
@@ -319,6 +321,18 @@ void sigchld_handler(int sig)
child->exit_status = status;
child->dead = 1;
+ fprintf(stderr, "child %d returned: ", pid);
+ if (WIFEXITED(status)) {
+ if (WEXITSTATUS(status))
+ exit_global = EXIT_FAILURE;
+ fprintf(stderr, "exited with status %d\n",
+ WEXITSTATUS(status));
+ } else if WIFSIGNALED(status) {
+ fprintf(stderr, "killed by signal %d\n",
+ WTERMSIG(status));
+ } else {
+ fprintf(stderr, "unknown reason\n");
+ }
}
}
@@ -660,5 +674,5 @@ int main(int argc, char *argv[])
signal(sigexit, SIG_DFL);
raise(sigexit);
}
- exit(EXIT_SUCCESS);
+ exit(exit_global);
}
--
2.19.1
Re: Segmentation error 6 in rt_heap_create() without --enable-pshared
On 11/7/18 4:09 PM, Henning Schild wrote:
> Am Wed, 7 Nov 2018 14:31:10 +0100
> schrieb Philippe Gerum :
>
>> On 11/7/18 2:00 PM, Henning Schild via Xenomai wrote:
>>> Readding list ...
>>>
>>
>> Does this help?
>>
>> diff --git a/lib/copperplate/heapobj-heapmem.c
>> b/lib/copperplate/heapobj-heapmem.c index 5c0ce9b2d..124fe564a 100644
>> --- a/lib/copperplate/heapobj-heapmem.c
>> +++ b/lib/copperplate/heapobj-heapmem.c
>> @@ -33,8 +33,8 @@ int __heapobj_init_private(struct heapobj *hobj,
>> const char *name, int ret;
>>
>> if (mem == NULL) {
>> -_mem = __STD(malloc(size));
>> -if (_mem == NULL)
>> +mem = __STD(malloc(size));
>> +if (mem == NULL)
>> return -ENOMEM;
>> }
>>
>> @@ -43,16 +43,16 @@ int __heapobj_init_private(struct heapobj *hobj,
>> const char *name, else
>> snprintf(hobj->name, sizeof(hobj->name), "%p", hobj);
>>
>> -ret = heapmem_init(hobj->pool, _mem, size);
>> +hobj->pool = mem;
>> +hobj->size = size;
>> +
>> +ret = heapmem_init(hobj->pool, mem, size);
>
> ret = -EINVAL
Part of the solution in this patch (on top of the previous one), but more
changes are needed for a complete fix:
diff --git a/lib/copperplate/heapobj-heapmem.c
b/lib/copperplate/heapobj-heapmem.c
index 124fe564a..3961bd054 100644
--- a/lib/copperplate/heapobj-heapmem.c
+++ b/lib/copperplate/heapobj-heapmem.c
@@ -33,6 +33,7 @@ int __heapobj_init_private(struct heapobj *hobj, const char
*name,
int ret;
if (mem == NULL) {
+ size = HEAPMEM_ARENA_SIZE(size); /* Count meta-data in. */
mem = __STD(malloc(size));
if (mem == NULL)
return -ENOMEM;
@@ -60,7 +61,7 @@ int heapobj_init_array_private(struct heapobj *hobj, const
char *name,
size_t size, int elems)
{
return __bt(__heapobj_init_private(hobj, name,
- HEAPMEM_ARENA_SIZE(size * elems), NULL));
+ size * elems, NULL));
}
int heapobj_pkg_init_private(void)
--
Philippe.
Re: [PATCH v2 4/8] net/tcp: Copy data back to user buffer in rt_tcp_recvmsg
On 06.11.18, 19:52, Jan Kiszka wrote:
> On 06.11.18 11:00, Sebastian Smolorz via Xenomai wrote:
> > A bug in rt_tcp_recvmsg() prevented an application to receive data
> > over an RTTCP socket. Data was not copied back to the application's
> > buffer but rather into a temporary kernel buffer.
> >
> > Signed-off-by: Sebastian Smolorz
> > ---
> >
> > kernel/drivers/net/stack/ipv4/tcp/tcp.c | 13 +++--
> > 1 file changed, 3 insertions(+), 10 deletions(-)
> >
> > diff --git a/kernel/drivers/net/stack/ipv4/tcp/tcp.c
> > b/kernel/drivers/net/stack/ipv4/tcp/tcp.c index 2678e6a..3242a08
> > 100644
> > --- a/kernel/drivers/net/stack/ipv4/tcp/tcp.c
> > +++ b/kernel/drivers/net/stack/ipv4/tcp/tcp.c
> > @@ -2084,17 +2084,10 @@ static ssize_t rt_tcp_recvmsg(struct rtdm_fd
> > *fd, struct user_msghdr *msg, int m>
> > len = iov[0].iov_len;
> > if (len > 0) {
> >
> > - buf = xnmalloc(len);
> > - if (buf == NULL) {
> > - ret = -ENOMEM;
> > - goto out;
> > - }
> > - ret = rtdm_copy_from_user(fd, buf, iov[0].iov_base, len);
> > - if (!ret)
> > - ret = rt_tcp_read(fd, buf, len);
> > - xnfree(buf);
> > + buf = iov[0].iov_base;
> > + ret = rt_tcp_read(fd, buf, len);
>
> Does this go well with smap? IOW: Was everything testing on a system
> with smap support available and enabled?
smap was enabled. Tests were executed on an Atom E3845. cat /proc/
cpuinfo showed no smap flag.
> > }
> >
> > -out:
> > +
> >
> > rtdm_drop_iovec(iov, iov_fast);
> >
> > return ret;
--
Sebastian
