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>