[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150312.153130.1372889580818723770.davem@redhat.com>
Date: Thu, 12 Mar 2015 15:31:30 -0400 (EDT)
From: David Miller <davem@...hat.com>
To: hadarh@....mellanox.co.il
Cc: gregkh@...uxfoundation.org, amirv@...lanox.com,
netdev@...r.kernel.org, hadarh@...lanox.com, yevgenyp@...lanox.com,
ogerlitz@...lanox.com, talal@...lanox.com,
shannon.nelson@...el.com, dledford@...hat.com,
greearb@...delatech.com, gregory.v.rose@...el.com,
jeffrey.t.kirsher@...el.com, jesse.brandeburg@...el.com,
john.ronciak@...el.com
Subject: Re: [PATCH net-next V1 0/3] net/mlx4_core: Allow setting init-time
device specific parameters
From: Hadar Hen Zion <hadarh@....mellanox.co.il>
Date: Thu, 12 Mar 2015 20:59:26 +0200
> On Thu, Mar 12, 2015 at 8:05 PM, David Miller <davem@...emloft.net> wrote:
>> From: Hadar Hen Zion <hadarh@....mellanox.co.il>
>> Date: Thu, 12 Mar 2015 10:07:35 +0200
>>
>>> On Wed, Mar 11, 2015 at 7:14 PM, David Miller <davem@...emloft.net> wrote:
>>>>
>>>> From: Amir Vadai <amirv@...lanox.com>
>>>> Date: Wed, 11 Mar 2015 11:08:50 +0200
>>>>
>>>> > Also, customers are paying for a very sophisticated piece of
>>>> > hardware, and we would like to enable power user to tweak it in some
>>>> > situtations. Of course the default mode should be used in 99% of the
>>>> > use cases.
>>>>
>>>> How much money someone pays for your hardware has nothing to do with
>>>> the standards by which we design userspace interfaces to configure
>>>> these devices.
>>>>
>>>> These textual interfaces are arbitrary, and you are choosing it only
>>>> because you cannot come up with a more reasonable scheme,
>>>>
>>>> I'm not applying these changes.
>>>> --
>>>
>>> In previous conversations Greg suggested us to use configfs.
>>>
>>> Is this case a misuse of configfs? maybe configfs should be deprecated... Greg?
>>>
>>> Is a scheme based on netlink will be acceptable by you?
>>
>> A portable, well typed, interface that other vendors could use if their
>> hardware had similar features would be acceptable.
>
> Do you mean an interface implementation that reminds the ethtool
> private flags scheme but implemented through netlink, allows
> configuration without a netdevice and more flexibility?
I mean exactly what I said, neither more nor less.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists