lkml.org 
[lkml]   [2004]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.136 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site