lkml.org 
[lkml]   [2003]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: POSIX message queues
Krzysztof Benedyczak wrote:

>Hello
>
>For quite a long time there are two implementations of posix mqueues
>around. I think it is time to decide at least if both of them have
>chances of beeing applied to official kernel. So I would
>like to know if Peter Waechtler's implementations is considered superior
>or there is possible some discussion and further work on our
>implementation is worthwhile.
>
>
Could you try to merge your work? Or at least: look at each others work.
For example Krzysiek/Michal's implementation has wake-one semantics,
which is IMHO a requirement.

Krzysiek: What is MQ_IOC_CLOSE? It looks like a stale ioctl. Please
remove such code from the patch.

The last time I looked at your patch I noticed a race between creation and setting queue attributes. Did you fix that?


>There are a lot of differencies but if the most important one is use of
>ioctl vs syscalls it can be changed (in fact our implementation loong time
>ago used syscalls).
>
>
I personally prefer syscalls, but that's just my personal preference.
For example the notification info is a structure, and printing it to a
text stream and then parsing it back again is just odd. And I don't see
how you can fix the O_CREAT+unusual mq_maxmsg races.
Why do you check against MQ_MAXMSG in user space? That's wrong. The
kernel will reject too large limits, probably depending on
/proc/sys/kern/ configuration. Checking in user space doesn't gain
anything, except that you loose the ability for runtime changes.
Please reuse the load_msg/store_msg functions instead of a
kmalloc(arg.msg_len, GFP_KERNEL) + copy_from_user. kmalloc(16384) is not
reliable - it needs a continuous block of 16 kB, and after a long
runtime, the memory is so fragmented that such memory may not exist.
This is a known problem for x86_64: They would prefer to have 16 kB
blocks for the stack, but this results in errors during stress testing.
proc_write_max_queues: off-by-one error. tmp[16] ='\0' overwrites the stack.
Is is necessary that the filesystem is visible to user space? What about
chroot environments, or environments with per-user mount points. I don't
like the dependence on /proc/mounts.

>In another words: is our implementation in the position
>of NGPT or better? ;-)
>
>
Do you know if Ulrich Drepper has looked at your user space libraries?
Your code must end up in glibc, and he's the maintainer.

--
Manfred

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.066 / U:1.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site