From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: Fwd: [ofa-general] FW: QLogic vNIC Kernel Submission Date: Wed, 18 Jun 2008 13:19:22 +0200 Message-ID: <4858EF3A.7080500@trash.net> References: <99863D2ED484D449811D97A4C44C9CBD7C50F7@EPEXCH2.qlogic.org> <4858E6E2.8050609@garzik.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Amar Mudrankit , netdev@vger.kernel.org, rdreier@cisco.com, Ramachandra K , poornima.kamath@qlogic.com To: Jeff Garzik Return-path: Received: from stinky.trash.net ([213.144.137.162]:60958 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752659AbYFRLTZ (ORCPT ); Wed, 18 Jun 2008 07:19:25 -0400 In-Reply-To: <4858E6E2.8050609@garzik.org> Sender: netdev-owner@vger.kernel.org List-ID: Jeff Garzik wrote: > Amar Mudrankit wrote: >> ---------- Forwarded message ---------- >> From: John Russo >> Date: Tue, Jun 17, 2008 at 6:36 PM >> Subject: [ofa-general] FW: QLogic vNIC Kernel Submission >> To: general@lists.openfabrics.org >> >> >> It looks as if my original email was "scrubbed" before it made the >> mailing list so I am resending it... >> >> QLogic has been attempting to submit our virtual NIC (vNIC) driver to >> the Linux kernel for several months. We have made changes to the code >> based on the feedback we have received over four rounds of >> submissions. Among the feedback we received during this process was a >> request to alter our code to use a single value per file for >> configuration of our driver through sysfs interface. After spending >> much time and effort to complete this change to our design we >> re-submitted the driver only to receive a response suggesting that we >> change once again from this interface to a different API interface >> called rtnl_link. Needless to say I am very frustrated with this >> process. This new API interface would require substantial changes to >> our code. >> >> QLogic has met the initial request to move to a single valued sysfs >> interface and I would hope that this new request will be waived and >> will not be a roadblock to inclusion of our driver to the kernel. > > One option is to get the base driver into the tree, sans sysfs > interface, and wait for the netlink interface. > > As Patrick noted, it is very important to -not- just throw new user > interfaces into the tree, because that essentially sets them in stone at > that point, needing to be supported as an Application Binary Interface > (ABI). > > The other stuff, like duplication of existing interfaces and strange > FSM-based netdev registration, are problems that could be worked out > in-tree, I suppose. That sounds fine to me. The duplication is even going away automatically with removal of the sysfs interface.