Date: Fri, 14 Aug 2009 10:49:24 -0700 From: "Li, Qing" <qing.li@bluecoat.com> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, "Qing Li" <qingli@freebsd.org> Cc: freebsd-net@freebsd.org, "Andrey V. Elsukov" <bu7cher@yandex.ru>, d@delphij.net, Julian Elischer <julian@elischer.org> Subject: RE: RFC: interface description Message-ID: <B583FBF374231F4A89607B4D08578A430503351D@bcs-mail03.internal.cacheflow.com> In-Reply-To: <20090813182918.S93661@maildrop.int.zabbadoz.net> References: <4A83EEA8.5080202@delphij.net> <4A840DA1.600@yandex.ru><4A844FF2.9000307@elischer.org> <20090813182918.S93661@maildrop.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>=20
> My point has always been - if I have to add/do an ioctl I can always
> also use a library call that will read it from a .txt, .xml, .db file
> or whatever and I don't have to go to the kernel, handle all the
> string length problems there, ... especially as the kernel cannot do
> anything with that string.
>=20
The interface description feature is a useful feature. Quite a few
products out there actually put a label on the physical box so it's
reasonable to have the ability to label the ports in the kernel.
There are quite a few embedded systems and not-so-standalone boxes
out there that are derivatives of FreeBSD. These systems might not
have the luxury of a file system. And getting coredumps from the
field with such information embedded in the ifnet{} just makes
debugging field issues a little bit easier.
>
> So here comes the usual catch 22 on a classic PC system:
> you can change everything.
>
> Using RFC 2553 Section 4 is probably the best indeed but has=20
> drawbacks as well.
>
Seems rather off topic ...
-- Qing
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B583FBF374231F4A89607B4D08578A430503351D>