>> Add a driver that provides a character special device for each
>> InfiniBand port. This device allows userspace to send and
>> receive MADs via write() and read() (with some control
>> operations implemented as ioctls).
Greg> Do you really need these ioctls?
Greg> This could be in a sysfs file, right?
The API version definitely can be, good point.
Greg> You are letting any user, with any privilege register or
Greg> unregister an "agent"?
They have to be able to open the device node. We could add a check
that they have it open for writing but there's not really much point
in opening this device read-only.
Greg> And shouldn't you lock your list of agent ids when adding or
Greg> removing one, or are you relying on the BKL of the ioctl
Greg> call? If so, please document this.
Each file has an "agent_mutex" rwsem that protects this... the global
list of agents handled by the lower level API is protected by its own locking.
Greg> Also, these "agents" seem to be a type of filter, right? Is
Greg> there no other way to implement this than an ioctl?
ioctl seems to be the least bad way to me. This really feels like a
legitimate use of ioctl to me -- we use read/write to handle passing
data through our file descriptor, and ioctl for control of the
properties of the descriptor.
What would you suggest as an ioctl replacement?
Thanks,
Roland
_______________________________________________
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
