On 02/27/15 22:22, Gleb Smirnoff wrote: > I'm the guy, who often breaks compilation of net-snmp on FreeBSD, > changing layout of kernel structures. And I'm about to change them > even more this year. However, I'd like to keep net-snmp working. > But it looks like, I won't be able to do that without your help, > since patches are about to be not trivial. > > In the first place, the idea to use kvm(3) library to read kernel > memory and traverse in kernel pointers was a very bad idea. The > library should actually be used only for debugging purposes, not > for production. It requires /dev/mem access, which implies increased > priveleges for application, making it less secure. It doesn't > participate in kernel locking, so any list traversals via > kernel pointers can eventually lead to accessing wrong memory. > The last, but not the least: it requires knowledge of the very > guts of kernel, and thus makes compilation of your program > very fragile as underlying system changes from release to release. > > This ends in of tons of #ifdef __FreeBSD_version, __DragonFly_version, > OpenBSD_version, NetBSD_, etc., and uncomprehendable code finally. > I hope, everyone agrees on this. > > Meanwhile, all BSD systems historically provided getifaddrs(3) > library function, that allows to obtain interface and address > information via a stable and non-priveleged API. Unfortunately, > most application developers constantly ignored getifaddrs(3) and > used kvm(3). My guess is that happened due to native netstat(1) > being kvm(3) based, and developers learned on how to obtain info > on network structures from its sources. They assumed that if > internal utility uses kvm(3), then this is the right way. > > So, as part of my network stack work, I started to convert both > internal and external utilities to proper API: > > https://svnweb.freebsd.org/base?view=revision&revision=256512 > https://github.com/miniupnp/miniupnp/commit/7f6cf3680e3fd539402c7576440cf7b1760ee088 > http://freshbsd.org/commit/freebsd-ports/r369861 > http://freshbsd.org/commit/freebsd-ports/r369851 > http://freshbsd.org/commit/freebsd-ports/r369841 > http://freshbsd.org/commit/freebsd-ports/r369827 > > Now time for net-snmp, which isn't piece of cake. And I'd like > to get it done properly, and not to store a patch in FreeBSD port > for ages, but to integrate the patch right in the main net-snmp repo. > So, I'm asking for your help here. Waiting for a net-snmp developer > to respond to this email, so that we can work on the problem together.
That sounds like a great plan. If you can post a patch on this mailing list or in the Net-SNMP patch tracker (http://sourceforge.net/p/net-snmp/patches/) then we can review it. Bart. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
