linux-kernel - Re: [PATCH 06/15] net: hbl

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]

Message-ID: <d79c7f3a-c770-4ef5-b9be-20f0c214b09f@habana.ai>
Date: Mon, 24 Jun 2024 07:21:24 +0000
From: Omer Shpigelman <oshpigelman@...ana.ai>
To: Andrew Lunn <andrew@...n.ch>
CC: Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "ogabbay@...nel.org" <ogabbay@...nel.org>,
        Zvika Yehudai <zyehudai@...ana.ai>
Subject: Re: [PATCH 06/15] net: hbl_cn: debugfs support

On 6/23/24 18:02, Andrew Lunn wrote:
>>> If there is no netdev, what is the point of putting it into loopback?
>>> How do you send packets which are to be looped back? How do you
>>> receive them to see if they were actually looped back?
>>>
>>> 	Andrew
>>
>> To run RDMA test in loopback.
> 
> What is special about your RDMA? Why do you need something which other
> vendors don't? Please solve this problem for all RDMA devices, not
> yours.
> 
> This all part of the same thing with respect to module
> parameters. Vendors would add module parameters for something. Other
> vendors would have the same concept, but give it a different name,
> different values. It was all poorly documented. You had to read the
> kernel sources to figure out what kernel module parameters do. Same
> goes for debugfs, driver values in /proc, /sysfs or /debugfs. So for
> years we have been pushing back on things like this.
> 
> If you have something which is unique to your hardware, no other
> vendor is ever going to have the same, then you can make an argument
> for something driver specific in /debugfs. But RDMA loopback tests is
> clearly not specific to your driver. Extend the KAPI and tools to
> cover this, document the KAPI, write the man page, and let other
> vendors implement the little bit they need in their driver, so users
> have a uniform way of doing things over a rather of devices.
> 
> You will get a lot of pushback on everything in /debugfs, so please
> review them all with this in mind.
> 
>        Andrew

I see your point and I'll keep that in mind. For these kinds of
configurations we can use devlink instead of debugfs.