POSIX message queues port
I have ported the POSIX messages queues NetBSD implementation to Dfly, for the
Summer of Code project.
The code is available here:
It is synced (hence the -sync in the branch name) with the latest netbsd
changes. I will be removing the debug k/printfs the following days, plus any
other commented out code of the original source (hence the -clean part).
I have written a bunch of test cases, which are available here:
There s also a utility that lists active message queues similar to ipcs(1).
$ gcc kvm-mqueue.c -o kvm-mqueue -lkvm -Wall -W -ansi -pedantic
$ sudo ./kvm-mqueue
Global list of the message queues:
Name Ptr Mode Flags Ref MaxMsg MsgSze CurMsg
/nonblock 0xcc7c3780 rwxr--r-- RW-- 0 32 1004 0
/many 0xcc796924 rwxr--r-- RWB- 5 32 1004 0
/tmqoc2 0xcc796780 rwxr-xr-x RWB- 0 32 1004 0
The port works very well. There are some glitches, but I`d rather tackle them,
after it is integrated to master.
I have also ran an almost-complete pbulk to verify that I haven t broken
horribly the pkgsrc. I have managed to compile ~6200 packages and at that point
I didn t have more than 700 failures.
I could use a helping hand though on how to handle the merge. Perhaps I should
do a squash merge and then create the following commits?
1. mqueues commit
2. librt commit
3. other stuff that don t fit to 1/2
Any thoughts/ideas would be appreciated.
#1 Updated by alexh about 6 years ago
I agree that the commits should be squashed into a handful, each to some part
of the code. I would suggest splitting it into the mqueues kernel part, mqueues
userland part, misc kernel and misc userland, if that applies.
What glitches are you talking about? What effect do they have? What pkgsrc that
currently build won't build with this port, and why?
#2 Updated by Anonymous about 6 years ago
Hey Alex, thanks for commenting.
Some problems for instance:
2. Our lack of signal queues has some implications with mq_notify() not working
100% as the standard expects.
3. There is a stale read-only useless (because currently we lack mqueues
support) p1003_1b.mq_open_max sysctl variable, that needs to be removed. When I
took a look at it in the summer it was part of some hackerish code and didnt
So things like that. Not fatal, but need to be solved eventually.
As for pkgsrc, I didnt complete the bulk build, because at some point that I
needed to resume it, it started building all the packages from scratch! And
after 14 days of building, I didnt have the patience to start all over again.
Also I didnt check which packages I broke (if any), because that would require a
non-mqueue bulk build to compare with, which I just can't afford resources-wise.
The bottom line is that I didnt introduce any significant breakage. Based on
hassos@ reports, we already have ~700 package failures.
#4 Updated by alexh about 6 years ago
For what it's worth, I think this can get commited once you are ready. The
issues you mentioned don't seem too bad, and overall, importing your code into
master will help getting it tested thoroughly in a number of scenarios.
As for the pkgsrc packages, I have a feeling that this won't have any negative
#5 Updated by Anonymous about 6 years ago
Ok, we are on a committing course!
The code has been cleaned up and the commits were squashed into more meaningful
I'm doing world/kernel builds, as I write this. I will then run the test suite,
just to make sure that I didn't break anything in the process of consolidating
the commits and I'll push to crater at weekend.
Unless someone objects of course.