netdev - RE: [PATCH iproute2] uapi: add vdpa.h

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: <PH0PR12MB5481AAD7096EA95956ED6801DC8C9@PH0PR12MB5481.namprd12.prod.outlook.com>
Date:   Mon, 18 Jul 2022 16:40:30 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        David Ahern <dsahern@...il.com>
Subject: RE: [PATCH iproute2] uapi: add vdpa.h

+ David

Hi Stephen,

> From: Stephen Hemminger <stephen@...workplumber.org>
> Sent: Monday, July 18, 2022 12:31 PM
> 
> Iproute2 depends on kernel headers and all necessary kernel headers should
> be in iproute tree. When vdpa was added the kernel header file was not.
> 
> Fixes: c2ecc82b9d4c ("vdpa: Add vdpa tool")
> Signed-off-by: Stephen Hemminger <stephen@...workplumber.org>

> ---
>  include/uapi/linux/vdpa.h | 59
> +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 59 insertions(+)
>  create mode 100644 include/uapi/linux/vdpa.h
> 
> diff --git a/include/uapi/linux/vdpa.h b/include/uapi/linux/vdpa.h new file
> mode 100644 index 000000000000..94e4dad1d86c
> --- /dev/null
> +++ b/include/uapi/linux/vdpa.h

We kept this in vdpa/include/uapi/linux/vdpa.h after inputs from David.
This is because vdpa was following rdma style sync with the kernel headers.
Rdma subsystem kernel header is in rdma/include/uapi/rdma/rdma_netlink.h.

Any reason to take different route for vdpa?
If so, duplicate file from vdpa/include/uapi/linux/vdpa.h should be removed.
So that there is only one vdpa.h file.

If so, should we move rdma files also similarly?

Similar discussion came up in the past. (don't have ready reference to the discussion).
And David's input was to keep the way it is like rdma.

Added him for his inputs if something changed lately.