++ don't ioctl / sockopt unless you absolutely have to for backward compatibility. It's an old hazardous design. We have oodles of space for symbols even on modern embedded systems.

What is the recommended way under Linux then? It seemed like everyone was going full steam ahead with adding devices under /dev and /proc with control via read/write/ioctl. ioctl in my experience has been the best way to add a clean, modular interface to kernel modules since you don't need to hack in syscalls or do terrible, custom shared memory communication.

The context isn't Linux (an UNIX clone, ioctl is endemic there, no hope).

It is fatfs, a tiny fat library for embedded use, which most of the time will be used w/o an OS.

Netlink is becoming common, but it's also messy because well, it started as a single purpose interface and is now among other things a misnomer as it's not limited to network link controls.

kdbus could probably provide richer interfaces eventually, but proximity to freedesktop will probably perpetuate a certain amount of pushback.

The main point is that the ioctl interface is limited in its expression. It is hard to filter for security, and have bad evolutionary properties. Many of the subprotocol designs over the top of ioctl have memory safety hazards even beyond the immediate issue of needing to often make and trim buffers in less than ideal ways. This is to say the interface is hard to design well with, and a more formally typed system would provide a better solution.

Regardless, OP isn't on Linux, and the point is to not copy the bad interface!

It just works.