Vinícius Miguel (Sep 03 2021 at 17:29): Vinícius Miguel (Sep 03 2021 at 17:29):Hello everyone!
I'd like to contribute to rsix and would like some guidance as to things I could implement or issues I could solve
Chris Fallin (Sep 03 2021 at 17:32):Hello and welcome! cc @Dan Gohman for this -- he might have some thoughts on good starter issues
Dan Gohman (Sep 03 2021 at 18:28):Hello! Are there specific features you're interested in working on, or are you looking for ideas? :-)
Vinícius Miguel (Sep 03 2021 at 18:58):Hello Dan and Chris! :D
Nothing in specific right now (although making bindings for mlock and mlockall would be nice), I'd be happy helping in any way possible
Dan Gohman (Sep 03 2021 at 19:16):As it happens, I implemented mlock just yesterday :-)
Dan Gohman (Sep 03 2021 at 19:17):But not mlockall, so that's something you could start with
Dan Gohman (Sep 03 2021 at 19:28):And along those lines, mincore, msync, mremap
Vinícius Miguel (Sep 03 2021 at 19:35):Right on!!
I've faced the same MCL_ONFAULT issue before and resorted to FFI in order to get it (https://github.com/vrmiguel/bustd/blob/master/cc/helper.c)
Would that be suitable for rsix or should we just ignore this constant for now?
Dan Gohman (Sep 03 2021 at 19:39):In general, it's fine to ignore stuff. In effect, we're currently ignoring all the MCL_* flags, so just implementing some of them is progress :-)
Dan Gohman (Sep 03 2021 at 19:44):Also, yeah, in general we want to stay away from emulating things, or providing our own definitions. If someone really wants MCL_ONFAULT, the linux_raw backend should get it from linux-raw-sys (which already has a definition of MCL_ONFAULT), and the libc backend should get it from libc (which doesn't yet, so the first step would be to add it upstream)
Vinícius Miguel (Sep 03 2021 at 20:08):No problem :D
I've open a PR for mlockall and munlockall although it's still a WIP (no linux_raw support yet)
Vinícius Miguel (Sep 03 2021 at 20:09):I've previously done a conversion for mlockall's errnos into proper Rust error enums
Err(match errno() {
// Some or all of the memory identified by the operation could not be locked when the call was made.
EAGAIN => Error::CouldNotLockMemoryError,
// The flags argument is zero, or includes unimplemented flags.
EINVAL => Error::InvalidFlagsError,
// Locking all of the pages currently mapped into the address space of the process
// would exceed an implementation-defined limit on the amount of memory
// that the process may lock.
ENOMEM => Error::TooMuchMemoryToLockError,
// The calling process does not have appropriate privileges to perform the requested operation
EPERM => Error::NoPermission,
// Should not happen
_ => Error::UnknownMlockallError,
})
are higher-level error enums like that out of place for rsix?
Dan Gohman (Sep 03 2021 at 20:19):That's a good question. rsix doesn't yet provide any enums like that, but that doesn't mean it shouldn't.
Dan Gohman (Sep 03 2021 at 20:20):For the more portable system calls, enums like that would sometimes get tricky, becuase there are a lot of subtle errno differences between eg. Linux and FreeBSD and other things.
Dan Gohman (Sep 03 2021 at 20:33):I think my gut feeling is that rsix shouldn't define enums like that; that can be done in higher-level APIs that wrap rsix. But it's just a feeling, and I could be convinced otherwise.
Vinícius Miguel (Sep 08 2021 at 14:08):Makes sense!
Vinícius Miguel (Sep 08 2021 at 14:09):Hey there, Dan!
I plan on finishing the PR soon(-ish), I just haven't had great availability :-P
Dan Gohman (Sep 08 2021 at 14:13):Hi! No worries :-)
Vinícius Miguel (Oct 13 2021 at 19:07):hey @Dan Gohman !
so sorry for the delay
Dan Gohman (Oct 13 2021 at 20:02):Hello!
Dan Gohman (Oct 18 2021 at 16:46):Is there anything you're blocked on, or that's confusing?
Last updated: Nov 22 2024 at 17:03 UTC