Re: [PATCH 0 of 20] [RFC] ipath - PathScale InfiniPath driver

[ebiederm@xmission.com (Eric W. Biederman)]

"Bryan O'Sullivan" <bos@pathscale.com> 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