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-prev] [day] [month] [year] [list]
Message-Id: <20100331.191844.186998605.davem@davemloft.net>
Date:	Wed, 31 Mar 2010 19:18:44 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	dm@...lsio.com
Cc:	shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [PATCH 5/6] cxgb4: Add main driver file and driver Makefile

From: Dimitris Michailidis <dm@...lsio.com>
Date: Wed, 31 Mar 2010 18:34:31 -0700

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

Yes, since procfs is essentially deprecated these days.

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

It's in fact easier to retain API by using sysfs.  Instead of having
to worry about the format of a procfs file listing entries one by one
per line, under sysfs you just add a new file to export new values.

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

What nodes you create under your own device object in sysfs is your
domain and your business.  Since it's one value per file there is no
real complexity in making sure tools can display the values properly.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ