netdev - Re: [PATCH 5/6] cxgb4: Add main driver file and driver Makefile

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]

Message-ID: <4BB3F827.3010402@chelsio.com>
Date:	Wed, 31 Mar 2010 18:34:31 -0700
From:	Dimitris Michailidis <dm@...lsio.com>
To:	David Miller <davem@...emloft.net>
CC:	shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [PATCH 5/6] cxgb4: Add main driver file and driver Makefile

David Miller wrote:

>> So, I propose getting rid of 3-4 of these files that are of lesser
>> value and moving the rest to debugfs for now.  If some alternative
>> through ethtool or something becomes available I can get rid of
>> anything that can be handled through a more general facility.  Would
>> that be acceptable?
> 
> You can use sysfs.

sysfs is a possibility but I thought Stephen's initial concern was that I 
was adding too many of these proc files and that they were creating a 
potential API.  sysfs will result in a lot more files with its 
value-per-file model and I think sysfs and proc are similar in "APIness". 
So it's not clear to me how going to sysfs would address Stephen's point. 
The remove-a-few plus move-to-debugfs proposal was in order to end up with 
fewer files in a non-API filesystem.

As these builtin switches become more common I expect an official way to 
represent and access them will emerge but maybe it's not a good idea to 
introduce a sysfs model for them as part of this driver submission.
--
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