Add support for the ioctl(2) facility #11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds initial basic support for the
ioctl(2)
facility long missing from OCaml. By specifying only the nullary command version (i.e., suitable only toioctl_list(2)
requests that don't take any argument), this initial implementation is of limited utility but also a no-brainer to provide as a bare minimum.As you'll note in the evolution of the commit history for this branch, I've checked that the signature is compatible with at least Linux, Darwin, FreeBSD, OpenBSD, and NetBSD. The obsolescent POSIX definition of
ioctl(2)
has hence been superseded in actual practice by all major platforms of note.In terms of future directions to extend this to a fully-functional unary-argument version, I believe that there are four distinct cases to handle:
ioctl(fd, cmd, arg)
, wherearg
is an immediate integer input argument.ioctl(fd, cmd, &arg)
, wherearg
is an integer input/output argument.ioctl(fd, cmd, buf)
, wherearg
is effectively aconst void*
input argument.ioctl(fd, cmd, &buf)
, wherearg
is effectively avoid*
input/output argument.The first case would be trivial, but I'd appreciate guidance on what an extended interface for all the above might best look like in terms of the conventions of and facilities provided by ExtUnix. Two options that come to mind would be to either provide a variant type to facilitate case analysis of the argument, or else to provide (at least) four distinct functions (e.g.,
ioctl_int
, etc). Thoughts?