proposal: x/sys/unix: make withData public #65903
Comments
seankhliao
changed the title
|
To clarify: what are you trying to do? IIRC my intent was to avoid exposing an unsafe.Pointer in the API, in favor of exposing type-safe wrappers for each type we need. |
|
I want to issue an ioctl call that passes as an argument an Ifreq struct that holds custom ifr data that is a Alternatively, one could add an interface to set 64bit values or even arbitrary byte slices to |
|
A pointer to what struct exactly? Is there a concrete C struct we can generate to give you a type safe API for this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Proposal Details
The ifreq functionality through the Ifreq interface and its IoctlIfreq interface currently do not offer the flexibility it could have.
A simple example would be to issue some ioctl where ifr should be a pointer.
There are of course workarounds for that (e.g. issuing raw ioctls via the syscall API and providing a byte slice) but adding a more robust interface like already supposed would be a good idea.
I currently don't see any reason why not to expose this already existing functionality, but maybe I miss a bigger structural point here.
If you do not have enough resources for implementing this change I'd be happy to help you out on that.
The code suggests that @mdlayher once thought about exporting access to IfreqData, but postponed it due accessibility through IoctlGetEthtoolDrvinfo. This although is read only.
The text was updated successfully, but these errors were encountered: