RDMA/cma: Remove netlink interface of CMA statistics
RFC PATCH 1/1 RDMA/cma: Remove netlink interface of CMA statistics
From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/[email protected]>
CMA statistics were exposed to users through netlink interface long time ago, but it wasn't exposed using netlink extensibility approach. The current implementation was based on struct and not attributes.
Let's remove it, before anyone is actually start to use it and prevents us to write it properly.
--- drivers/infiniband/core/cma.c | 82 --------------------------------------- drivers/infiniband/core/netlink.c | 4 +- include/uapi/rdma/rdma_netlink.h | 28 +------------ 3 files changed, 3 insertions(+), 111 deletions(-)
drivers/infiniband/core/cma.c +0 -82
@@ -4387,84 +4387,6 @@ static void cma_remove_one(struct ib_device *device, void *client_data)kfree (cma_dev); } -static int cma_get_id_stats (struct sk_buff *skb,struct netlink_callback *cb) -{ -struct nlmsghdr *nlh; -struct rdma_cm_id_stats *id_stats; -struct rdma_id_private *id_priv; -struct rdma_cm_id *id =NULL ; -struct cma_device *cma_dev; -int i_dev =0 , i_id =0 ; - -/* -* We export all of the IDs as a sequence of messages. Each -* ID gets its own netlink message. -*/ -mutex_lock (&lock); - -list_for_each_entry (cma_dev, &dev_list, list) { -if (i_dev < cb->args[0 ]) { - i_dev++; -continue ; - } - - i_id =0 ; -list_for_each_entry (id_priv, &cma_dev->id_list, list) { -if (i_id < cb->args[1 ]) { - i_id++; -continue ; - } - - id_stats =ibnl_put_msg (skb, &nlh, cb->nlh->nlmsg_seq, -sizeof *id_stats,RDMA_NL_RDMA_CM , -RDMA_NL_RDMA_CM_ID_STATS , -NLM_F_MULTI ); -if (!id_stats) - goto out; - -memset (id_stats,0 ,sizeof *id_stats); - id = &id_priv->id; - id_stats->node_type = id->route.addr.dev_addr.dev_type; - id_stats->port_num = id->port_num; - id_stats->bound_dev_if = - id->route.addr.dev_addr.bound_dev_if; - -if (ibnl_put_attr (skb, nlh, -rdma_addr_size (cma_src_addr (id_priv)), -cma_src_addr (id_priv), -RDMA_NL_RDMA_CM_ATTR_SRC_ADDR )) - goto out; -if (ibnl_put_attr (skb, nlh, -rdma_addr_size (cma_dst_addr (id_priv)), -cma_dst_addr (id_priv), -RDMA_NL_RDMA_CM_ATTR_DST_ADDR )) - goto out; - - id_stats->pid = id_priv->owner; - id_stats->port_space = id->ps; - id_stats->cm_state = id_priv->state; - id_stats->qp_num = id_priv->qp_num; - id_stats->qp_type = id->qp_type; - - i_id++; - } - - cb->args[1 ] =0 ; - i_dev++; - } - -out: -mutex_unlock (&lock); - cb->args[0 ] = i_dev; - cb->args[1 ] = i_id; - -return skb->len; -} - -static const struct rdma_nl_cbs cma_cb_table[] = { - [RDMA_NL_RDMA_CM_ID_STATS ] = { .dump = cma_get_id_stats}, -}; -static int cma_init_net (struct net *net) {struct cma_pernet *pernet =cma_pernet (net);
@@ -4514,7 +4436,6 @@ static int __init cma_init(void)if (ret) goto err; -rdma_nl_register (RDMA_NL_RDMA_CM , cma_cb_table);cma_configfs_init ();return 0 ;
@@ -4531,7 +4452,6 @@ static int __init cma_init(void) static void __exit cma_cleanup(void) {cma_configfs_exit (); -rdma_nl_unregister (RDMA_NL_RDMA_CM );ib_unregister_client (&cma_client);unregister_netdevice_notifier (&cma_nb);rdma_addr_unregister_client (&addr_client);
@@ -4540,7 +4460,5 @@ static void __exit cma_cleanup(void)destroy_workqueue (cma_wq); } -MODULE_ALIAS_RDMA_NETLINK (RDMA_NL_RDMA_CM ,1 ); -module_init (cma_init);module_exit (cma_cleanup);
drivers/infiniband/core/netlink.c +1 -3
@@ -58,7 +58,6 @@ EXPORT_SYMBOL(rdma_nl_chk_listeners);static bool is_nl_msg_valid (unsigned int type,unsigned int op) {static const unsigned int max_num_ops[RDMA_NL_NUM_CLIENTS ] = { - [RDMA_NL_RDMA_CM ] =RDMA_NL_RDMA_CM_NUM_OPS , [RDMA_NL_IWCM ] =RDMA_NL_IWPM_NUM_OPS , [RDMA_NL_LS ] =RDMA_NL_LS_NUM_OPS , [RDMA_NL_NLDEV ] =RDMA_NLDEV_NUM_OPS ,
@@ -176,8 +175,7 @@ static int rdma_nl_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh,return -EPERM ;/* FIXME: Convert IWCM to properly handle doit callbacks */ -if ((nlh->nlmsg_flags &NLM_F_DUMP ) || index ==RDMA_NL_RDMA_CM || - index ==RDMA_NL_IWCM ) { +if ((nlh->nlmsg_flags &NLM_F_DUMP ) || index ==RDMA_NL_IWCM ) {struct netlink_dump_control c = { .dump = cb_table[op].dump, };
include/uapi/rdma/rdma_netlink.h +2 -26
@@ -4,8 +4,7 @@#include <linux/types.h> enum { -RDMA_NL_RDMA_CM =1 , -RDMA_NL_IWCM , +RDMA_NL_IWCM =2 ,RDMA_NL_RSVD ,RDMA_NL_LS ,/* RDMA Local Services */ RDMA_NL_NLDEV ,/* RDMA device interface */
@@ -13,8 +12,7 @@ enum { };enum { -RDMA_NL_GROUP_CM =1 , -RDMA_NL_GROUP_IWPM , +RDMA_NL_GROUP_IWPM =2 ,RDMA_NL_GROUP_LS ,RDMA_NL_NUM_GROUPS };
@@ -23,17 +21,6 @@ enum {#define RDMA_NL_GET_OP (type) (type & ((1 << 10) - 1))#define RDMA_NL_GET_TYPE (client, op) ((client << 10) + op) -enum { -RDMA_NL_RDMA_CM_ID_STATS =0 , -RDMA_NL_RDMA_CM_NUM_OPS -}; - -enum { -RDMA_NL_RDMA_CM_ATTR_SRC_ADDR =1 , -RDMA_NL_RDMA_CM_ATTR_DST_ADDR , -RDMA_NL_RDMA_CM_NUM_ATTR , -}; -/* iwarp port mapper op-codes */ enum {RDMA_NL_IWPM_REG_PID =0 ,
@@ -47,17 +34,6 @@ enum {RDMA_NL_IWPM_NUM_OPS }; -struct rdma_cm_id_stats { -__u32 qp_num; -__u32 bound_dev_if; -__u32 port_space; -__s32 pid; -__u8 cm_state; -__u8 node_type; -__u8 port_num; -__u8 qp_type; -}; -enum {IWPM_NLA_REG_PID_UNSPEC =0 ,IWPM_NLA_REG_PID_SEQ ,
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171113144024.26655-1-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Quoted 8 lines · Leon Romanovsky
From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/[email protected]>
CMA statistics were exposed to users through netlink interface long time ago, but it wasn't exposed using netlink extensibility approach. The current implementation was based on struct and not attributes.
Let's remove it, before anyone is actually start to use it and prevents us to write it properly.
You should describe why you think it is safe to remove a uAPI from the kernel in the commit message.. When was it introduced? Why was a uAPI added with no users??
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171113192432.GL6918-uk2M96/[email protected]
Quoted 7 lines · Jason Gunthorpe
Quoted 6 lines · Leon Romanovsky
From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/[email protected]>
CMA statistics were exposed to users through netlink interface long time ago, but it wasn't exposed using netlink extensibility approach. The current implementation was based on struct and not attributes.
Quoted 6 lines
Quoted 2 lines
Let's remove it, before anyone is actually start to use it and prevents us to write it properly.
You should describe why you think it is safe to remove a uAPI from the kernel in the commit message.. When was it introduced? Why was a uAPI added with no users??
I didn't want to invest time before I actually see that it is possible. The purpose of this RFC is to hear feedback and see if anyone cares enough about that code.
The code was introduced a long time ago [1] as an attempt to provide netstat-like information. It had simple demo application, which didn't work for me, before I started to refactor ib_netlink.
Also latest fixes from Parav in the actual callback implementation support my feelings that the kernel part is broken too.
Is it enough to proceed with the submission of actual patch?
Thanks
Quoted 2 lines
Jason
A message that is not in the archive (sent off-list or not yet received): 20171114080550.GR18825-U/[email protected]
Quoted 16 lines · Leon Romanovsky
Quoted 7 lines · Jason Gunthorpe
Quoted 6 lines · Leon Romanovsky
From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/[email protected]>
CMA statistics were exposed to users through netlink interface long time ago, but it wasn't exposed using netlink extensibility approach. The current implementation was based on struct and not attributes.
Quoted 6 lines
Quoted 2 lines
Let's remove it, before anyone is actually start to use it and prevents us to write it properly.
You should describe why you think it is safe to remove a uAPI from the kernel in the commit message.. When was it introduced? Why was a uAPI added with no users??
Quoted 5 lines
I didn't want to invest time before I actually see that it is possible. The purpose of this RFC is to hear feedback and see if anyone cares enough about that code.
The code was introduced a long time ago [1]
missing ref
Quoted 3 lines
as an attempt to provide netstat-like information. It had simple demo application, which didn't work for me
what didn't work exactly?
This is UAPI, if you want to remove it, make sure to provide a good replacement and see
if/what is the upstream procedure for UAPI changes/removals, I guess there is such, sending
email to a subsystem list doesn't seem enough to me.
Quoted 7 lines
before I started to refactor
ib_netlink.Also latest fixes from Parav in the actual callback implementation support my feelings that the kernel part is broken too.
Is it enough to proceed with the submission of actual patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAJ3xEMhfdXz8zQFetjQPfe7HZiCi+N0z6r9XSucuTzQo1--PBg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 17 lines · Or Gerlitz
Quoted 16 lines · Leon Romanovsky
Quoted 13 lines · Jason Gunthorpe
Quoted 8 lines · Leon Romanovsky
From: Leon Romanovsky <leonro-VPRAkNaXOzVWk0Htik3J/[email protected]>
CMA statistics were exposed to users through netlink interface long time ago, but it wasn't exposed using netlink extensibility approach. The current implementation was based on struct and not attributes.
Let's remove it, before anyone is actually start to use it and prevents us to write it properly.
You should describe why you think it is safe to remove a uAPI from the kernel in the commit message.. When was it introduced? Why was a uAPI added with no users??
Quoted 8 lines
Quoted 5 lines
I didn't want to invest time before I actually see that it is possible. The purpose of this RFC is to hear feedback and see if anyone cares enough about that code.
The code was introduced a long time ago [1]
missing ref
Quoted 8 lines
Quoted 4 lines
as an attempt to provide netstat-like information. It had simple demo application, which didn't work for me
what didn't work exactly?
Started from compilation, continued to wrong data presented. There is no need to carry 7-years old code, which no one cares about it.
Quoted 4 lines
This is UAPI, if you want to remove it, make sure to provide a good replacement and see
if/what is the upstream procedure for UAPI changes/removals,
So, are you going to fight removal of DECnet support from netdev?
https://patchwork.ozlabs.org/patch/837484/
It is going to break user experience of Debian and Ubuntu 9.10 lovers.
http://retrocmp.com/decnet/decnet-on-ubuntu-setup
Quoted 2 lines
I guess there is such, sending
email to a subsystem list doesn't seem enough to me.
Maybe for you it is not enough, for Linus it is enough and for other subsystems which removed user visible changes is enough too.
https://patchwork.kernel.org/patch/9788849/
https://www.spinics.net/lists/linux-btrfs/msg66769.html
Thanks
Quoted 13 lines
Quoted 9 lines
before I started to refactor
ib_netlink.Also latest fixes from Parav in the actual callback implementation support my feelings that the kernel part is broken too.
Is it enough to proceed with the submission of actual patch?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171114095605.GU18825-U/[email protected]
Quoted 4 lines · Leon Romanovsky
Quoted 1 line
what didn't work exactly?
Started from compilation, continued to wrong data presented. There is no need to carry 7-years old code, which no one cares about it.
If it legiminately doesn't actually work then that is reason enough to be able to drop a uAPI, IMHO.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171114152350.GA4263-uk2M96/[email protected]
Quoted 9 lines · Jason Gunthorpe
Quoted 4 lines · Leon Romanovsky
Quoted 1 line
what didn't work exactly?
Started from compilation, continued to wrong data presented. There is no need to carry 7-years old code, which no one cares about it.
If it legiminately doesn't actually work then that is reason enough to be able to drop a uAPI, IMHO.
I'm propose proper patch at -rc1 phase. It will give enough time to test it and revert before next merge window.
Thanks
Quoted 6 lines
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Leon Romanovsky
Quoted 1 line · Or Gerlitz
what didn't work exactly?
Started from compilation, continued to wrong data presented. There is no need to carry 7-years old code, which no one cares about it.
The cma kernel code doesn't compile for seven years, impossible.. you are referring maybe to some user-space code. Re presenting wrong data, again, you mean the user-space code or the kernel code sending wrong data to user-space? please be precise.
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAJ3xEMhM0xfNxRU+37oWKq_w=MGtE3sUXy38bARgX5-3G9zhvw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 5 lines · Or Gerlitz
Quoted 3 lines · Leon Romanovsky
Quoted 1 line · Or Gerlitz
what didn't work exactly?
Quoted 7 lines
Quoted 2 lines
Started from compilation, continued to wrong data presented. There is no need to carry 7-years old code, which no one cares about it.
The cma kernel code doesn't compile for seven years, impossible.. you are referring maybe to some user-space code. Re presenting wrong data, again, you mean the user-space code or the kernel code sending wrong data to user-space? please be precise.
User-space application didn't compile and kernel sent wrong data.
Can you help me to find an answer to my initial question? Are you using this CMA netlink interface? yes/no? Do you know anyone who is using this interface? yes/no?
Thanks
Quoted 6 lines
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171114173516.GZ18825-U/[email protected]
Quoted 9 lines · Leon Romanovsky
Quoted 8 lines · Or Gerlitz
Quoted 6 lines · Leon Romanovsky
Quoted 1 line · Or Gerlitz
what didn't work exactly?
Started from compilation, continued to wrong data presented. There is no need to carry 7-years old code, which no one cares about it.
Quoted 6 lines
Quoted 4 lines
The cma kernel code doesn't compile for seven years, impossible.. you are referring maybe to some user-space code. Re presenting wrong data, again, you mean the user-space code or the kernel code sending wrong data to user-space? please be precise.
User-space application didn't compile and kernel sent wrong data.
Can you answer my question and point out the code that provides wrong data to user-space?!
Quoted 3 lines
Can you help me to find an answer to my initial question? Are you using this CMA netlink interface?
Do you know anyone who is using this interface?
The rdma netlink code existed way before you got there and it has various UAPIs that were/are used by multiple vendors..
AFAIK we had @ Voltaire some management/provisioning SW that used these CMA UAPIs and I am not sure where did it go after the V-acquisition --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAJ3xEMgJJX0FXMK9Rj=kGmNGkF14tBe03zfwzKHnEEp=cEDVxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 11 lines · Or Gerlitz
Quoted 3 lines · Leon Romanovsky
Can you help me to find an answer to my initial question? Are you using this CMA netlink interface?
Do you know anyone who is using this interface?The rdma netlink code existed way before you got there and it has various UAPIs that were/are used by multiple vendors..
AFAIK we had @ Voltaire some management/provisioning SW that used these CMA UAPIs and I am not sure where did it go after the V-acquisition
I got my answers, you are not using this CMA netlink part and don't know anyone real with real code who uses.
Thanks
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171115052926.GN18825-U/[email protected]
Quoted 7 lines · Leon Romanovsky
Quoted 6 lines · Or Gerlitz
Quoted 3 lines · Leon Romanovsky
Can you help me to find an answer to my initial question? Are you using this CMA netlink interface?
Do you know anyone who is using this interface?
Quoted 8 lines
Quoted 5 lines
The rdma netlink code existed way before you got there and it has various UAPIs that were/are used by multiple vendors..
AFAIK we had @ Voltaire some management/provisioning SW that used these CMA UAPIs and I am not sure where did it go after the V-acquisition
I got my answers, you are not using this CMA netlink part and don't know anyone real with real code who uses.
This is UAPI, and you want to delete it, so your job is to go through all the required
procedures for that.
But before that, you ignored my question asking what is broken in the current code, please don't.
You can't come to someone's code say it's broken without providing the data and ask to revert it.
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAJ3xEMjrTvY+hq=1Q3tmPk_QiZtpO8dLMmCtrPjJgbtOeiU=6Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 5 lines · Or Gerlitz
But before that, you ignored my question asking what is broken in the current code, please don't.
You can't come to someone's code say it's broken without providing the data and ask to revert it.
Doug, Jason,
I have asked multiple times what is broken in the cma netlink code and no answer.
Please suggest how to proceed with this patch, there's a claim there that the code
which is removed has issues but no data is given.
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAJ3xEMjst4EaFYfUVwqiOzsh5pVPj85joPYsGsap8p6tQYUwew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 8 lines · Or Gerlitz
Quoted 5 lines · Or Gerlitz
But before that, you ignored my question asking what is broken in the current code, please don't.
You can't come to someone's code say it's broken without providing the data and ask to revert it.
Quoted 8 lines
Doug, Jason,
I have asked multiple times what is broken in the cma netlink code and no answer.
Please suggest how to proceed with this patch, there's a claim there that the code
which is removed has issues but no data is given.
Well, I would like to know the issues as well, as I've already said I think they should be described in the commit message.
But also, at the RFC stage the onus is on other people, particularly people that want to keep the feature, to explain where it is being used and why..
We need to decide if we drop the RFC and fix the implementation, apply the the RFC, or add a deprecation printk warning, or something..
Please try to be productive here and concentrate on adding information and not nit-picking the process! We all know removing a uapi is a big deal.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171120194152.GN29075-uk2M96/[email protected]
Quoted 6 lines · Jason Gunthorpe
Well, I would like to know the issues as well, as I've already said I think they should be described in the commit message.
But also, at the RFC stage the onus is on other people, particularly people that want to keep the feature, to explain where it is being used and why..
we did it to allow user space track rdma-cm connections through the rdma subsystem netlink infra-structure, e.g one can come up with netstat like reporting of rdma listeners and connections, this is it!
Quoted 2 lines
We need to decide if we drop the RFC and fix the implementation, apply the the RFC, or add a deprecation printk warning, or something..
right. To my opinion, if there are issues in the implementation, lets fix them, I don't see why remove this implementation and replace it with a new one that does the same thing.
Quoted 3 lines
Please try to be productive here and concentrate on adding information and not nit-picking the process! We all know removing a uapi is a big deal.
Re usage I provided what I know.
When a patch is sent to remove code "which has problems" and the author doesn't provide any information on the nature nor the details of the problems after being asked three times - what this has to do with nit picking or processes?
it's something totally different, isn't that?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): CAJ3xEMhKEXB3-RJFyEh2dE8dr6OOpQPZ2rJ14MoKQ-2sB0GTXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 5 lines · Or Gerlitz
Quoted 2 lines · Jason Gunthorpe
Well, I would like to know the issues as well, as I've already said I think they should be described in the commit message.
Quoted 7 lines
Quoted 3 lines
But also, at the RFC stage the onus is on other people, particularly people that want to keep the feature, to explain where it is being used and why..
we did it to allow user space track rdma-cm connections through the rdma subsystem netlink infra-structure, e.g one can come up with netstat like reporting of rdma listeners and connections, this is it!
And after 7 years did anyone use it? The answer is no and it is because this interface was added without any real user space application which was supposed to use it.
Quoted 7 lines
Quoted 3 lines
We need to decide if we drop the RFC and fix the implementation, apply the the RFC, or add a deprecation printk warning, or something..
right. To my opinion, if there are issues in the implementation, lets fix them, I don't see why remove this implementation and replace it with a new one that does the same thing.
Just looking at the code without deep dive.
1. Lack of extensibility, in case of desire to add new field to rdma_cm_id_stats, you will need to throw away this struct and add new netlink attribute.
2. Device list lock for data retrieval - user can prevent device from recovery (maybe).
3. It doesn't return device ID !!!!!
4. Completely unscalable by sending message per-struct and not using netlink nested tables.
5. No check of device identifiers -> returns everything.
4. There is no nlmsg_end at the end of message.
Are you going to fix it?
Quoted 6 lines
Quoted 4 lines
Please try to be productive here and concentrate on adding information and not nit-picking the process! We all know removing a uapi is a big deal.
Re usage I provided what I know.
It is wishful thinking, I'm interested in real users and real applications. Do you know about such?
Thanks