- 主题:访问proc系统内容有啥高效方法吗
比如访问
proc/sys/net/ipv4/conf下内容
正常做法是open,read,close
但是proc下这种文件很多,如果需要高效访问,有什么其他技巧吗
我目前想用ioctl,但是不知道proc下这些内容,储存在内核的什么地方
还是使用sysctl? man了下好像已经废弃了
Use of this system call was long discouraged: since Linux 2.6.24, uses of this system call result in warnings in the kernel log, and in Linux 5.5, the system
call was finally removed. Use the /proc/sys interface instead.
Note that on older kernels where this system call still exists, it is available only if the kernel was configured with the CONFIG_SYSCTL_SYSCALL option. Fur?
thermore, glibc does not provide a wrapper for this system call, necessitating the use of syscall(2).
--
修改:b0207191 FROM 59.61.184.*
FROM 112.111.1.*
能把需求说细一点吗?
proc/sys/net/ipv4/conf
这个也不怎么改啊,快点慢点差不多。
除非某个地方每秒访问好几千次。
--
FROM 223.72.70.*
还是看具体需求吧,或者在内核下通过 netlink 机制上报一些数据,是不是可以满足你的一些需求,不过这种可能得改内核代码了
--
FROM 111.199.107.*
比如访问
/proc/sys/net/ipv4/neigh/vlan15下的若干节点
anycast_delay
app_solicit
base_reachable_time
base_reachable_time_ms
delay_first_probe_time
gc_stale_time
locktime
mcast_resolicit
mcast_solicit
proxy_delay
proxy_qlen
retrans_time
retrans_time_ms
ucast_solicit
unres_qlen
unres_qlen_bytes
这些节点都是在同一个网络接口下配置/属性/状态,
与其调用16次open read close ,有没有方法一次获取这16个信息,
特别是设备上网络接口N较多的时候, 相当于要执行16*N次操作,
【 在 ameng 的大作中提到: 】
能把需求说细一点吗?
proc/sys/net/ipv4/conf
这个也不怎么改啊,快点慢点差不多。
除非某个地方每秒访问好几千次。
--
FROM 218.66.32.*
chatgpt回答挺好
req.hdr.nlmsg_len = NLMSG_LENGTH(sizeof(struct ndmsg));
req.hdr.nlmsg_type = RTM_GETNEIGH;
req.hdr.nlmsg_flags = NLM_F_REQUEST | NLM_F_DUMP;
req.hdr.nlmsg_seq = 1;
req.hdr.nlmsg_pid = getpid();
req.ndm.ndm_family = AF_INET;
用netlink可以,用这个关键字搜吧
man 7 rtnetlink
【 在 b0207191 的大作中提到: 】
: 比如访问
: /proc/sys/net/ipv4/neigh/vlan15下的若干节点
: anycast_delay
: ...................
--
FROM 27.38.197.*
我说说想法哈,不一定合适,您根据实际情况考量。
比如有 100 个 vlan,并且不是太经常修改。
-- 比如每分钟不超过 1 次修改,就算不太经常。
这个量,我觉得就用普通的文件打开读的方式就行。
每次 16*100 = 1.6k 个文件打开、读、关闭操作。若干秒一次,对操作系统负担应该不算重。
如果 vlan 比这个量大很多,而且经常变化。
可能得进到这块的内核看看,里面数据结构是怎么构成的。
看看能不能一次把内核数据结构全部导出来,在应用层解析。理论上这样文件 I/O 的操作可以每次收集就一个打开,然后 IOCTL 就行了。但是这个对开发要求很高,而且内核数据结构的调整不会通知你,一旦内核升级的时候数据结构调整了,得跟着升级。
------------------
还有就是经常调整 vlan 这个需求不太常规。
如果您的业务需求是下位机需要临时连上 vlan 干点啥,然后马上拆。
我倒是建议把这个业务挪到应用层处理。
【 在 b0207191 的大作中提到: 】
: 比如访问
: /proc/sys/net/ipv4/neigh/vlan15下的若干节点
: anycast_delay
: ...................
--
FROM 221.216.116.*
请问下, 大家平时看linux源代码发现看不懂的,都有直接问代码作者吗?
最近看3.x kernel/sysctl.c这部分代码,感觉比较复杂,有些函数逻辑不太理解
比如struct ctl_table_header *__register_sysctl_paths(
struct ctl_table_root *root,
struct nsproxy *namespaces,
const struct ctl_path *path, struct ctl_table *table)
中
for (set = header->set; set; set = set->parent) {
struct ctl_table_header *p;
list_for_each_entry(p, &set->list, ctl_entry) {
if (p->unregistering)
continue;
try_attach(p, header);
}
}
这部分,循环,为什么要对每个p都做个try_attach
【 在 ameng 的大作中提到: 】
我说说想法哈,不一定合适,您根据实际情况考量。
比如有 100 个 vlan,并且不是太经常修改。
-- 比如每分钟不超过 1 次修改,就算不太经常。
这个量,我觉得就用普通的文件打开读的方式就行。
每次 16*100 = 1.6k 个文件打开、读、关闭操作。若干秒一次,对操作系统负担应该不算重。
如果 vlan 比这个量大很多,而且经常变化。
可能得进到这块的内核看看,里面数据结构是怎么构成的。
看看能不能一次把内核数据结构全部导出来,在应用层解析。理论上这样文件 I/O 的操作可以每次收集就一个打开,然后 IOCTL 就行了。但是这个对开发要求很高,而且内核数据结构的调整不会通知你,一旦内核升级的时候数据结构调整了,得跟着升级。
------------------
还有就是经常调整 vlan 这个需求不太常规。
如果您的业务需求是下位机需要临时连上 vlan 干点啥,然后马上拆。
我倒是建议把这个业务挪到应用层处理。
【 在 b0207191 的大作中提到: 】
: 比如访问
: /proc/sys/net/ipv4/neigh/vlan15下的若干节点
: anycast_delay
: ...................
--
FROM 218.66.32.*
不知道为啥 attach
这个 header 是啥玩意?
好像是给一棵树从某个节点一直到根的所有节点所在层都做一下 attach。
【 在 b0207191 的大作中提到: 】
: 请问下, 大家平时看linux源代码发现看不懂的,都有直接问代码作者吗?
: 最近看3.x kernel/sysctl.c这部分代码,感觉比较复杂,有些函数逻辑不太理解
: 比如struct ctl_table_header *__register_sysctl_paths(
: ...................
--
FROM 223.72.88.*
作者说这块代码太旧了,别管了。。。
This is a very old kernel.
The function you mention was removed over ten years ago and the way sysctls are registered today is completely different.
try_attach() was removed in
commit 7ec66d06362d ("sysctl: Stop requiring explicit management of sysctl directories") citing performance reasons.
This may be same performance issue you are encountering and maybe you can take inspiration from that commit to avoid it.
Or even better, upgrade to a newer kernel.
【 在 ameng 的大作中提到: 】
: 不知道为啥 attach
: 这个 header 是啥玩意?
: 好像是给一棵树从某个节点一直到根的所有节点所在层都做一下 attach。
: ...................
--
FROM 218.66.32.*