[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5f90fd26-e7bf-bb2a-01f2-6b166f2265e9@sandisk.com>
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.
Powered by blists - more mailing lists