netdev - RE: [E1000-devel] [net-next v4 7/8] i40e: sysfs and debugfs interfaces

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:	Thu, 5 Sep 2013 17:53:38 +0000
From:	"Nelson, Shannon" <shannon.nelson@...el.com>
To:	Stephen Hemminger <stephen@...workplumber.org>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
CC:	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"gospo@...hat.com" <gospo@...hat.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"sassmann@...hat.com" <sassmann@...hat.com>
Subject: RE: [E1000-devel] [net-next v4 7/8] i40e: sysfs and debugfs
 interfaces

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@...workplumber.org]
> Sent: Wednesday, September 04, 2013 5:38 PM

[...]

> Also, anything in sysfs is device specific and you really need to make
> a strong case for why your device is special and needs an exception.
> Other devices will have hardware switches and doing something through
> sysfs is going to create a pain for any controller application.
> 
> I vote against including the sysfs VEB stuff because it will become
> a lifetime ABI.

If we simply remove the VEB attributes (cvlan, mode, seid, svlan) but keep the model structure and the VSI attributes, will that satisfy your vote, or are you suggesting that we should drop the whole sysfs model that we implemented?

At this point after some discussion internally, we think it would be better to simply remove the whole sysfs module - it is an optional section with no direct operational requirement.  The intent was to get something started that looked useful, but perhaps we were a little premature in presenting this model for these new switch offload capabilities.

As Dave rightly pointed out, we may want to bring this back in the future, but I think that we have more work to do with the community in proposing and designing a switching model, if it really is even needed.  That's not an over-night thing, and we shouldn't be trying to patch up something that has fundamental concerns.  Also, bringing it back later when it isn't obscured by the rest of the driver might be more successful in getting community input.

sln

--
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