Open kbara opened 7 years ago
Thanks!
I think the CI is failing because of LuaJIT 2.0 vs 2.1 differences. I don't really want to break 2.0 yet, even though most people use 2.1. I think it should be possible to work around the differences, will take a look.
That won't give the right result though...
On 28 Oct 2016 8:15 p.m., "daurnimator" notifications@github.com wrote:
@daurnimator commented on this pull request.
In syscall/linux/types.lua https://github.com/justincormack/ljsyscall/pull/203#pullrequestreview-6302725 :
@@ -1016,6 +1016,74 @@ mt.cpu_set = {
addtype(types, "cpu_set", "struct cpu_set_t", mt.cpu_set)
+local ulong_bit_count = ffi.sizeof('unsigned long') * 8 +local function ulong_index_and_bit(n)
- local i = math.floor(n / ulong_bit_count)
- local b = bit.lshift(1ULL, n - i * ulong_bit_count)
Need to use 1 instead of 1ULL so that luajit 2.0 doesn't fail
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/justincormack/ljsyscall/pull/203#pullrequestreview-6302725, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdcPFwJRSGWJWXrV44Cd_h_e2ty9_4yks5q4kkkgaJpZM4KjkR9 .
This has significant (but not total) overlap with #193. The numa/mempolicy code is the same, but this one also includes the migrate_pages patch.
@kbara its not just the syntax, 2.0 does not have 64 bit shifts. There are some compatibility functions for 64 bit shifts here https://github.com/justincormack/ljsyscall/blob/master/syscall/bit.lua
Yeah - that was a hastily-written patch based on some Jabber discussion, which I should revert. Sorry for the noise.
Hi @justincormack ,
@wingo wrote a couple of patches to ljsyscall, which we've been using in the lwaftr. As per discussion with him, here's a PR upstreaming them. They deal with mempolicy/numa/page migration.