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