Date: Sat, 15 Aug 2009 16:34:42 +0200 From: Andre Oppermann <andre@freebsd.org> To: d@delphij.net Cc: "Li, Qing" <qing.li@bluecoat.com>, Brooks Davis <brooks@freebsd.org>, freebsd-net@freebsd.org, Qing Li <qingli@freebsd.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru>, Julian Elischer <julian@elischer.org>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Subject: Re: [Take 2] Re: RFC: interface description Message-ID: <4A86C782.5030808@freebsd.org> In-Reply-To: <4A8601CE.5030205@delphij.net> References: <4A83EEA8.5080202@delphij.net> <20090813182918.S93661@maildrop.int.zabbadoz.net> <B583FBF374231F4A89607B4D08578A430503351D@bcs-mail03.internal.cacheflow.com> <20090814193303.GA21941@lor.one-eyed-alien.net> <4A8601CE.5030205@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Xin LI wrote: > Hi, guys, > > Here is a patch that implements the functionality in userland (as > setifdescription/getifdescription functions in libutil); with this I > think we can also provide an option that some kernel feature (like Qing > Li said it might be useful for embedded systems, but of course the > kernel feature would require more careful design) being used without > modifying programs. This version uses if_dname plus if_dunit as > distinguished name, and a Berkeley DB (hash, /etc/ifdescr.db) to store > the information. I don't like this approach. Adding unconditional dependencies to libutil and libbsdxml unnecessarily complicates and bloats up ifconfig, which is a very central utility that resides on every rescue and minimal boot disk. Additionally the DB stored description can easily go out of sync when interface disappear and reappear. On top of that it complicates porting of routing daemons (Quagga suite, OpenBGPD/OSPFD). Having it only for ifconfig but nowhere else is not entirely pointless but seriously reduces its usefulness. IMHO interface description is a very useful feature and it should be stored in the kernel attached to struct ifnet. However it probably should only be a pointer to malloc'ed memory. It is only infrequently accessed and never in a critical code path. A slight disadvantage is either a separate IOCTL to retrieve the description or a little hack to copy it into struct ifnet just when it is retrieved by userspace from the kernel. [Which reminds me that somewhen we need something more flexible than the current routing socket.] -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A86C782.5030808>