Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
NetBSD support #3439
NetBSD support #3439
Conversation
Call pthread_setname_np with the correct number of arguments on NetBSD.
Hardlink libc functions to the correct version on NetBSD 10 since we do not use the micro-magic from C.
Updated core with some path related functions and did some minor code cleanup. Most of the standard library function is just a matter of copy what is there for the other BSDs.
Fixed broken thread policy causing deadlocks.
Just selecting the same codepath as other BSD's for the most part.
|
I think we are at a pretty good state right now. Would love to get some feedback. |
|
Add the appropriate build tag to |
Added build tag to rand_bsd.odin and fixed build warning.
I realize we should use PHYSMEM64 on NetBSD. So we can not share code with FreeBSD.
|
Ah sorry, you also need to exclude netbsd in the generic |
|
Are you sure netbsd doesn't have native futexes? |
I don't think so. :( (It could perhaps be called something else on NetBSD? I noticed it was not easy to find on FreeBSD either.) |
|
I think I can rewrite the futex implementation using raw syscalls. Will give it a go. |
|
Native futex support is in. Plz let me know if you have any other feedback. |
I looked into this a bit and came across this thread, which is concerning. Though the followup by thorpej seems to indicate that it may be usable in certain cases.
otoh Mesa doesn't use futexes on NetBSD when I peeked at the sourcecode, so I don't know if/how the followup progressed. https://man.netbsd.org/_lwp_park.2 and co might be the "right" thing to do, but NetBSD appears to be unique among the BSDs here. |
|
Hm.. yea. As for the current state of things I have hammered this code quite a bit and I have not found any issues. (That is not to say there is none.) But it could also be that this works well for Odin since the use of the API is quite simplistic, and it could be that most of the issues the Mesa team is experiencing comes from using more "complicated" patterns. Perhaps there use of futexes are not process private for example? I would prefer keeping the code as is and do wider testing. If we see any problems it is only a few lines of code to switch to the _lwp_park API. Most of the work would just be to read up on the API documentation. If this work, the codebase also gets cleaner because most code is just shared with Linux. :) |
|
There is now a working CI for Odin on NetBSD in a separate PR here #3482 |
This is my attempt at an initial port of Odin to NetBSD. It targets NetBSD 10.0 (AMD64) with Clang/LLVM 17 from
the pkgsrc wip sectionpkgsrc. If you don't want to taint your system withWIPlibraries you can build LLVM using the mksandbox tool.The current goal
(at the moment) is to have the compiler fully working on NetBSD as well as enough of the standard library to runis to have the NetBSD port be on par with the other BSD's.demo.odinRight now the compiler seems happy and the demo is running,
but there are concurrency issues in the runtime. This needs more investigation. One possible issue could be the thread id, that I do not know how to get a hold of atm and I'm currently investigating the issue. Another culprit could be the futex implementation that is pretty much the same as on Haiku.There is also room for some more cleanup and possible joining or refactoring some code that could be shared with other BSDs.
Generally this port follow the patterns outlined by the other BSD's.