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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210308162858.00004535@intel.com>
Date:   Mon, 8 Mar 2021 16:28:58 -0800
From:   Jesse Brandeburg <jesse.brandeburg@...el.com>
To:     kuba@...nel.org, davem@...emloft.net
Cc:     netdev@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
        alice.michael@...el.com, alan.brady@...el.com
Subject: [RFC net-next] iavf: refactor plan proposal

Hello,

We plan to refactor the iavf module and would appreciate community and
maintainer feedback on our plans.  We want to do this to realize the
usefulness of the common code module for multiple drivers.  This
proposal aims to avoid disrupting current users.

The steps we plan are something like:
1) Continue upstreaming of the iecm module (common module) and
   the initial feature set for the idpf driver[1] utilizing iecm.
2) Introduce the refactored iavf code as a "new" iavf driver with the
   same device ID, but Kconfig default to =n to enable testing. 
	a. Make this exclusive so if someone opts in to "new" iavf,
	   then it disables the original iavf (?) 
	b. If we do make it exclusive in Kconfig can we use the same
	   name? 
3) Plan is to make the "new" iavf driver the default iavf once
   extensive regression testing can be completed. 
	a. Current proposal is to make CONFIG_IAVF have a sub-option
	   CONFIG_IAVF_V2 that lets the user adopt the new code,
	   without changing the config for existing users or breaking
	   them.

We are looking to make sure that the mode of our refactoring will meet
the community's expectations. Any advice or feedback is appreciated.

Thanks,
Jesse, Alice, Alan

[1]
https://lore.kernel.org/netdev/20200824173306.3178343-1-anthony.l.nguyen@intel.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ