Skip site navigation (1)Skip section navigation (2)
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>