Hi Jiri, On 20/05/18 14:19, Jiri Pirko wrote: > Tue, Mar 27, 2018 at 05:43:08PM CEST, [email protected] wrote: >> On Sat, Oct 29, 2016 at 12:56:28PM +0200, Jiri Pirko wrote: >>>>> I strongly believe it is a huge mistake to use sysfs for things like >>>>> this. This should be done via generic netlink api. >>>> >>>> This doesn't change the problem that it is already that way. This patch >>>> only adds the list of available files to the README. >>> >>> Sure. Just found out you did it like that. Therefore I commented. I >>> suggest to rework the api to use genl entirely. >> >> Hi Jiri, >> >> Thanks for sharing your thoughts! >> >> Could you explain a bit more on which disadvantages you see in >> the usage of sysfs here? > > There are 2 major disadvantages. > 1) You don't have any events on a change. An app has to poll in order to > know what changed in kernel. Netlink handles this by sending > multicast messages on a specific socket while whoever is interested > gets the messages. > 2) In sysfs, everything is string. There are even mixed values like > "1 (means something)". There are no well defined values. Every driver > can expose same things differently. In Netlink, you have well-defined > attributes, with typed values. You can pass multiple attributes for > the same value if needed. > > In general, usage of sysfs in netdev subsystem is frowned upon. I would > suggest to convert your iface to Generic Netlink API and let the > existing sysfs API to rot.
Do you have any pointer about where this discussion took place? I imagine it happened in conjunction with some patches intended to other drivers/netdev changes. Reading that could give us a sense of how strict/important/severe this decision was and how to prioritize future work. I am asking because we have been working on a new feature since several months and this feature introduces a new sysfs knob. Now, although I understand the recommendation of switching to netlink, I find it a bit impractical to delay a new (and fairly big) feature, simply because it uses a potentially obsolete, but current, API. Any opinion about this? Thanks a lot Regards, -- Antonio Quartulli
signature.asc
Description: OpenPGP digital signature
