Hi Stephen,On the other hand, based on what you are saying about your device, it sounds like you are working on some kind of cryptographically secured (either authenticated or encrypted or both) tunnel, in which case the fact that security is easier to handle with netlink than ioctls becomes important. If you can't ensure security of the endpoint configuration, you can't ensure security of the tunnel itself.
Thanks for your response.
On Thu, Nov 12, 2015 at 5:34 PM, Stephen Hemminger
<stephen@xxxxxxxxxxxxxxxxxx> wrote:
The problem is ioctl's are device specific, and therefore create dependency
on the unique features supported by your device.
The question always comes up, why is this new API not something general?
In this case, it really is for unique features of my device. My device
has its own unique notion of a "peer" based on a particular elliptic
curve point and some other interesting things. It's not something
generalizable to other devices. The thing that makes my particular
device special is these attributes that I need to make configurable. I
think then, by your criteria, ioctl would actually be perfect. In
other words, I interpret what you wrote to mean "generalizable:
netlink. device-specific: ioctl." If that's a decent summary, then
ioctl is certainly good for me.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature