[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170119063326.GJ32481@mtr-leonro.local>
Date: Thu, 19 Jan 2017 08:33:26 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Bart Van Assche <bart.vanassche@...disk.com>
Cc: Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
Or Gerlitz <gerlitz.or@...il.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 Wed, Jan 18, 2017 at 01:45:14PM -0800, Bart Van Assche wrote:
> 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.
We didn't look deeply on sysfs mainly because it is unpopular
in netdev community. Maybe we were misled and it is simply not true.
>
> Bart.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists