Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify scratch processing #374

Open
joneschrisg opened this issue Sep 4, 2013 · 0 comments
Open

Simplify scratch processing #374

joneschrisg opened this issue Sep 4, 2013 · 0 comments

Comments

@joneschrisg
Copy link
Contributor

There's a lot of (rather deilcate) code in place to handle various cases around scratch-buffer management. I'd really like to simplify that if possible.

An idea that strikes me is that for syscalls like read() with unbounded buffer sizes, allocate scratch buffers on a best-effort basis, rather than all-or-none. The kernel can return as little data as it wants, so rr can take advantage of that to pass a smaller input buffer to the kernel if not enough scratch is available.

This would be unsound for syscalls with inoutparams, so it would still be possible to exhaust scratch, but those cases are so edge (deep sighandler interrupts of huge poll buffers, e.g.) I'm inclined not to care if it simplifies the code a lot.

In reality, there are certain "gentlemen's agreements" linux makes with userspace, like reads of 4096 bytes or under on files succeed or fail atomically, IIRC. And the notion of "best-effort" is horrendously hard to define for a syscall like recvmsg(). And ioctl()s and interacting with special devices ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant