netdev - Re: [PATCH 0/8] csiostor: Chelsio FCoE offload driver submission

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 24 Aug 2012 13:04:06 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	naresh@...lsio.com
Cc:	JBottomley@...allels.com, linux-scsi@...r.kernel.org,
	dm@...lsio.com, netdev@...r.kernel.org, chethan@...lsio.com
Subject: Re: [PATCH 0/8] csiostor: Chelsio FCoE offload driver submission

From: Naresh Kumar Inna <naresh@...lsio.com>
Date: Fri, 24 Aug 2012 03:57:45 +0530

> This is the initial submission of the Chelsio FCoE offload driver (csiostor)
> to the upstream kernel. This driver currently supports FCoE offload
> functionality over Chelsio T4-based 10Gb Converged Network Adapters.
> 
> The following patches contain the driver sources for csiostor driver and
> updates to firmware/hardware header files shared between csiostor and
> cxgb4 (Chelsio T4-based NIC driver). The csiostor driver is dependent on these
> header updates. These patches have been generated against scsi 'misc' branch.
> 
> csiostor is a low level SCSI driver that interfaces with PCI, SCSI midlayer and
> FC transport subsystems. This driver claims the FCoE PCIe function on the
> Chelsio Converged Network Adapter. It relies on firmware events for slow path
> operations like discovery, thereby offloading session management. The driver
> programs firmware via Work Request interfaces for fast path I/O offload
> features.

You are going to have to get rid of these module parameters.

That have to do with things that are in no way specific to your device,
and therefore should be configured using generic kernel facilities.

Using driver specific module parameters results in a poor user
experience, because in order to make a configuration change the user
has to know exactly what kind of device and driver is underneath,
and then learn what the unique method is to make that configuration
change.

If you use a generic facility, the user only needs to learn one way to
make a configuration change, regardless of device type and driver.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html