netdev - Re: [B.A.T.M.A.N.] [PATCH 03/17] batman-adv: Add network

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:   Sat, 4 Aug 2018 11:36:32 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Antonio Quartulli <a@...table.cc>
Cc:     The list for a Better Approach To Mobile Ad-hoc
         Networking <b.a.t.m.a.n@...ts.open-mesh.org>,
        Linus Lüssing <linus.luessing@...3.blue>,
        netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [B.A.T.M.A.N.] [PATCH 03/17] batman-adv: Add network_coding and
 mcast sysfs files to README

Sat, Aug 04, 2018 at 11:24:11AM CEST, a@...table.cc wrote:
>Hi Jiri,
>
>On 20/05/18 14:19, Jiri Pirko wrote:
>> Tue, Mar 27, 2018 at 05:43:08PM CEST, linus.luessing@...3.blue 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?

I agree, that does not make sense.

I just wanted you to consider introducing netlink iface and migrate to
it as it is generally the preffered way to comunicate with userspace in
networking area (I don't have pointer any specific discussion though -
it is just a common knowledge :)). I will be more then happy to help you
with that. You should look at net/core/devlink.c and net/wireless/nl80211.c
to get some inspiration.


>
>
>Thanks a lot
>
>
>Regards,
>
>
>-- 
>Antonio Quartulli
>