Messages in this thread | | | From | Roland Dreier <> | Date | Mon, 22 Nov 2004 15:05:40 -0800 | Subject | Re: [PATCH][RFC/v1][9/12] Add InfiniBand userspace MAD support |
| |
>> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |