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).

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.

Best regards,
Stathis

History

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?

Some problems for instance:
1. http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=412252. 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
touch it.

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.

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
impact.

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.