netdev - RE: Silicom bypass driver promote from staging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <3BFAEADE799AF145974162DF00E013AF018F814DAB@exchange2010.silicom.local>
Date:	Thu, 7 Aug 2014 09:26:54 +0000
From:	David Hendel <david@...icom.co.il>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	"arnd@...db.de" <arnd@...db.de>, Anna Lukin <annal@...icom.co.il>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: RE: Silicom bypass driver promote from staging

Hello Netdev group,

For the /driver/staging/silicom that we want to promote.
We have our bypass driver updated and we would like to move forward with integrating it into the kernel mainline We are not sure of what is the best location to have these driver located, as this is not really a network driver.
The options that we see are:
driver/misc/silicom/...
driver/char/silicom/...
driver/bypass/silicom/....

The description of the functionality of the driver is below per readme of this driver in the /driver/staging/silicom.

Currently in the attached driver we have defined it to be in driver/bypass/silicom/....
If this is OK with you then we can continue with that. if you thing that it needs to be in another location then we can change the patch.

Let me know how we can proceed with that. what should be the next step.
-------------
Theory of Operation:
The Silicom Bypass Network Interface Cards (NICs) are network cards with paired ports (2 or 4).
The pairs either act as a "wire" allowing the network packets to pass or insert the device in between the two ports.  When paired with the on-board hardware watchdog or other failsafe, they provide high availability for the network in the face of software outages or maintenance.

The software requirements are for a kernel level driver that interfaces with the bypass and watchdog, as well as for control software. User control can be either the provided standalone executable
(/bin/bpctl) or the API exposed by the Silicom library.  
----------------------

Regards, David

-----Original Message-----
From: gregkh@...uxfoundation.org [mailto:gregkh@...uxfoundation.org]
Sent: Monday, June 09, 2014 11:04 PM
To: David Hendel
Subject: Re: FW: ethtool patch to support bypass / fail-to-wire function

On Mon, Jun 09, 2014 at 07:29:08PM +0000, David Hendel wrote:
> Hello Greg Kroah-Hartman,
> 
> My name is David Hendel, I am Silicom V.P of R&D and was working with Anna Lukin our senior software developer to incorporate our bypass / Fail-to-Wire functionality into ethtool.
> 
> We have been working with our partner Citrix in doing that and they 
> think that it will be very valuable if this will be added to the kernel distribution ethtool We have our bypass driver already in the kernel  - /drivers/staging/silicom/ bpctl_mode ...

Ah, I was wondering what was up with that driver.  I wanted to remove it soon as it didn't seem like anyone was working on merging it to the "proper" place in the Linux kernel tree.  Are you planning on helping to clean up the code to get it merged properly soon?

> Per Ben Hutchings we need to work with networking community, not sure 
> if you are the one to approach,

Nope, I'm not a networking developer, try the netdev@...r.kernel.org mailing list, that is where the Linux kernel networking developers are at.

greg k-h

Download attachment "linux-3.16-rc6_silbp1.patch" of type "application/octet-stream" (628501 bytes)