Conversation
Awesome! Thanks for doing this.
I hope that doesn't stop us from merging this. At first glance the code looks good, modulo some cosmetic changes. |
|
Hi @jperkin, Thanks for your work in porting RethinkDB to SmartOS. The changes look great, except for some minor nit-picks:
(@AtnNn - What cosmetic changes were you thinking of?) |
Avoids conflicts with file_t from sys/file.h on SmartOS.
- Use std:: prefixes to avoid "Call to 'func' is ambiguous" errors. - Use C99 remainder() instead of legacy drem(). - Include <strings.h> for bzero(). - Cast pid_t to int for printing. - Remove unnecessary "friend class lock_t" to avoid lock_t conflicts.
- Add a new Event Ports backend for events and timers. - Use fcntl locking due to lack of flock(). - Support directio() on legacy file systems. - Support POLLRDHUP. - Use posix_madvise() and illumos pthread_*() routines. - Add endian support. - Restrict /proc/meminfo parsing and _gettid wrapper to Linux systems. - Add compat std::to_string implementation.
|
Thanks for the feedback. I've updated the pull request to incorporate these suggestions, and have also made a few fixes to the event port backend which seems to have resolved the issues I was seeing with the 64-bit build. Test results are now:
This is with my changes applied to the most recent v2.0.x branch. |
|
The changes look good to me. @AtnNn, what do you think? |
|
@jperkin This is phenomenal. Assigning @AtnNn for a final decision. @mglukhovsky Is this fine?
|
|
@jperkin -- are you completely opposed to signing the CLA (http://rethinkdb.com/community/cla/)? It's all online and only takes a few seconds. Unfortunately if we don't follow this process, we'll have to clear it with legal, which is doable but complicated. (We really appreciate the patch and want to merge it in, but bureaucracy demands to be served) |
|
Just to clarify, @jperkin works with me at Joyent -- and I think he was just trying to be expedient, not take a position against the CLA. If signing the CLA is the path to expediency, we can definitely make that happen... |
|
Thanks @bcantrill -- the CLA is definitely the most expedient path (but not the only one, if it's unworkable for you guys). FYI, all it does is signs off the copyright to these specific patches to RethinkDB. We included a lot of info in the CLA document on why that's necessary for us to operate effectively -- sorry if it causes too many inconveniences. |
|
OK, not a problem, you should have received a signed CLA from me now. |
|
Got it, thanks! @danielmewes @AtnNn -- feel free to merge if/when it's appropriate. |
|
I'm going to test it myself as soon as I get a SmartOS VM running. |
|
I found the cause of the missing |
|
@AtnNn Any particular reason why this has not been merged yet ? It's been almost 1 year... I would very much like to run RethinkDB on SmartOS. |
|
Thanks for the bump @tlvenn. I think we had some issues getting the VM set up the last time we tried. We should pick this up again soon. However note that we might not have the resources to fully test and support this even after merging into the main branch. |
|
Joyent is happy to provide SmartOS infrastructure for this. Please create an account for RethinkDB and then mail me ([email protected]) or DM me (@bcantrill) your username and we'll get it taken care of! |
|
Thanks @bcantrill, that's very helpful. I'll email you shortly. |
|
Hi @danielmewes , any progress you can update us with please ? Thanks ! |
|
I would like to see it merged as it will open possibilities to add more platforms. |
|
I want to add NetBSD support. |
|
@bcantrill @dalanmiller any update ? It's hard to believe Jonathan went through so much effort and it has been wasted for almost a year already... |
|
@tlvenn Sorry for the delayed reply, I was out of office for the past week. |
|
I merged current |
|
Thanks for the update @danielmewes ! |
|
There's currently a compilation issue with V8. Looking into work-arounds... |
|
I'm at a bit of a loss here. The final linking step for V8 fails as follows: Note that /root/rethinkdb/build/external/v8_3.30.33.16-patched/build/out/x64.release/obj.host/tools/gyp/libv8_base.a does exist, and reads it just fine. Still the GNU linker doesn't accept it. If I remove that input from the command, it just prints the same error for the next .a file in the list. The only report of a similar issue I could find was http://forums.mozillazine.org/viewtopic.php?f=42&t=344719 , which has no solution. |
|
An interesting thing is that |
|
Ok made some progress. Looks like the problem is that the V8 build system creates what's called a "thin" archive, which gld then doesn't accept (not sure if that's because of the missing |
|
V8 still doesn't link, though now with a different issue: @jperkin Do you remember how you got V8 to work back when you started porting RethinkDB? I think back then we might have been accepting a system-installed version of libv8, which probably made this easier. Right now we no longer support that. |
|
This might be related to https://github.com/joyent/pkgsrc-joyent/blob/master/rethinkdb/patches/patch-mk_support_pkg_v8.sh, or something similar where it is trying to e.g. build a 64-bit binary where the GCC default is 32-bit, or vice-versa. That's usually the cause of ELFCLASS failures. I also ensured that we used the system (pkgsrc) icu rather than building inline, which required this patch https://github.com/joyent/pkgsrc-joyent/blob/master/rethinkdb/patches/patch-external_v8__3.30.33.16_third__party_icu_icu.gyp Both of these are specific to the pkgsrc environment though and aren't general purpose. |
|
Sure. Let me know if I need to take a look at refreshing them to catch up with any changes since then. |
|
I don't see anything wrong with these changes, in the sense of scope or whatnot. (I didn't code review the new ifdefed out code.) If you can run clang, you might want to put I'm not sure if the |
|
I've repointed this PR at the |
This is a set of commits that add support for SmartOS.
file_ttomyfile_t,file_tis exposed fromsys/file.hon SmartOS.lock_ttomylock_t,lock_tis exposed fromsys/machtypes.hon SmartOS.With these changes applied I am able to run a server in both 32-bit and 64-bit builds. It should be broadly compatible with other illumos distributions and Oracle Solaris, but those have not been verified.
Running the unittest suite on 32-bit results in:
The
RDBBtree.SindexEraseRangefailure looks very similar to #3805:The
UtilsTest.IPAddressfailure is:For this test
ip_stringsonly contains203.0.113.59, so it may just need a change to handle thegetaddrinfo()handling on SmartOS.When running the test suite against the 64-bit build, I see intermittent failures in the Clustering tests with heartbeat timeouts, but haven't tracked those down yet, otherwise same results as the 32-bit build. Running the standalone server seems to work fine.
I have no real interest in retaining copyright and signing the CLA, so you can consider these changes as being in the public domain and are welcome to take them as your own.