netdev - Re: [RFC] RESEND - rdmatool

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:   Wed, 18 Jan 2017 13:45:14 -0800
From:   Bart Van Assche <bart.vanassche@...disk.com>
To:     Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
        Or Gerlitz <gerlitz.or@...il.com>
CC:     Leon Romanovsky <leonro@...lanox.com>,
        Ariel Almog <arielalmogworkemails@...il.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [RFC] RESEND - rdmatool - tool for RDMA users

On 01/18/2017 10:31 AM, Jason Gunthorpe wrote:
> I think it depends on what this tool is supposed to cover, but based
> on the description, I would start with netlink-only.
> 
> The only place verbs covers a similar ground is in 'device
> capabilities' - for some of that you might want to open a new-uAPI
> verbs fd, but even the capability data from that would not be
> totally offensive to be accessed over netlink.
> 
> IMHO netlink should cover almost everything found in sysfs today.

We would need a very strong argument to introduce a netlink API that
duplicates existing sysfs API functionality. Since the sysfs API is
extensible, why not extend that API further? E.g. the SCST sysfs API
shows that more is possible with sysfs than what most kernel drivers
realize.

Bart.