This is still work in progress and only a very small part of the ioctl
interface is reimplemented but I would like to get some comments before
the patchset becomes too big and changing things becomes too tedious.
The interface used for communication between ethtool and kernel is based on
ioctl() a
Mon, Dec 11, 2017 at 02:53:11PM CET, mkube...@suse.cz wrote:
>This is still work in progress and only a very small part of the ioctl
>interface is reimplemented but I would like to get some comments before
>the patchset becomes too big and changing things becomes too tedious.
>
>The interface used
From: Jiri Pirko
Date: Mon, 11 Dec 2017 17:32:46 +0100
> I think that it does not make sense to convert ethtool->netlink_ethtool
> 1:1 feature wise. Now we have devlink, ritch switch representation
> model, tc offload and many others. Lot of things that are in
> ethtool, should be done in devlink
Mon, Dec 11, 2017 at 06:01:44PM CET, da...@davemloft.net wrote:
>From: Jiri Pirko
>Date: Mon, 11 Dec 2017 17:32:46 +0100
>
>> I think that it does not make sense to convert ethtool->netlink_ethtool
>> 1:1 feature wise. Now we have devlink, ritch switch representation
>> model, tc offload and many
On 12/11/2017 09:01 AM, David Miller wrote:
> From: Jiri Pirko
> Date: Mon, 11 Dec 2017 17:32:46 +0100
>
>> I think that it does not make sense to convert ethtool->netlink_ethtool
>> 1:1 feature wise. Now we have devlink, ritch switch representation
>> model, tc offload and many others. Lot of th
On Mon, Dec 11, 2017 at 5:53 AM, Michal Kubecek wrote:
> This is still work in progress and only a very small part of the ioctl
> interface is reimplemented but I would like to get some comments before
> the patchset becomes too big and changing things becomes too tedious.
>
> The interface used f
On Tue, 12 Dec 2017 07:32:44 -0800, Roopa Prabhu wrote:
> Thanks for working on this!. Agree with most comments already
> discussed on this thread.
> I would prefer if we fold ethtool netlink into devlink since there is
> already an overlap.
> many reasons:
> - have just one driver api for device g
Michal,
Thanks for looking at this issue.
While the kernel and userland bits here are at least somewhat
decoupled, as the current maintainer for the userland ethtool I
feel compelled to comment. FWIW I had started down a similar road,
but I became dissatisfied with my own results. The main proble
From: "John W. Linville"
Date: Thu, 14 Dec 2017 16:07:56 -0500
> Even without considering the ioctl problesms, the current ethtool
> API seems a bit crufty. It has been a catch-all, "where else would it
> go?" dumping ground for a long time, and it has accrued a number of
> not-entirely-related b
