"Bryan O'Sullivan" <[EMAIL PROTECTED]> writes: > On Fri, 2005-12-30 at 16:10 -0800, Greg KH wrote: > >> But we (the kernel community), don't really accept that as a valid >> reason to accept this kind of code, sorry. > > Fair enough. I'd like some guidance in that case. Some of our ioctls > access the hardware more or less directly, while others do things like > read or reset counters.
As a general rule a driver should push as much functionality to libraries and the infrastructure code as possible. > Which of these kinds of operations are appropriate to retain as ioctls, > in your eyes, and which are best converted to sysfs or configfs > alternatives? > > As an example, take a look at ipath_sma_ioctl. It seems to me that > receiving or sending subnet management packets ought to remain as > ioctls, while getting port or node data could be turned into sysfs > attributes. Lane identification could live in configfs. If you think > otherwise, please let me know what's more appropriate. I haven't looked closely enough at the state of the openib tree but you should not need an additional interface to send/receive standard IB subnet management packets. That is something that should be provided the same way by all infiniband drivers. The only case I can think of where this might not already exist is the code that responds to the subnet manager. If the current interfaces are not sufficient then the infiniband layer needs more work. > The less blind I am in doing these conversions, the fewer rounds we'll > have to go in reviewing humongous driver submission patches :-) Given Linus's comments and looking at where you are getting stuck I would recommend you split out support for the nonstandard ipath protocol from the rest of the driver. If the standard infiniband interfaces for kernel bypass are not sufficient for flinging packets then we need to re-examine them. Eric _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
