Date: Sat, 15 Aug 2009 10:39:10 -0700 From: Julian Elischer <julian@elischer.org> To: Andre Oppermann <andre@freebsd.org> Cc: "Li, Qing" <qing.li@bluecoat.com>, Brooks Davis <brooks@freebsd.org>, d@delphij.net, freebsd-net@freebsd.org, Qing Li <qingli@freebsd.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru>, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Subject: Re: [Take 2] Re: RFC: interface description Message-ID: <4A86F2BE.4050203@elischer.org> In-Reply-To: <4A86C782.5030808@freebsd.org> 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> <4A86C782.5030808@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Andre Oppermann wrote: > 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.] > From my perspective, putting it in a separate db outside the kernel kind of defeats the purpose. I thought the first patches had the right idea. though for me the current ability to rename an interface is good enough. I mean is you can cal your interface "Sydney0" or "Melbourne2" that is really enough..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A86F2BE.4050203>