On Fri, Aug 14, 2009 at 10:49:24AM -0700, Li, Qing wrote:
> >
> > 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.
>
> 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.I think this is a decently compelling argument for in-kernel descriptions. They do solve some synchronization issues and one pointer is probably an acceptable price to pay given all the edge cases related to keeping a file in sync if you went the totally user land route. I general, I don't think we should try too hard to solve every problem here. Adding a pointer to ifnet, a quick get/set ioctl, ifconfig support, and support for ifdesc_<ifp> or similar variables in rc.conf is probably as much as makes sense to do. This is mostly a feature for appliance builders. If I were working on adding the ability to slim down ifnet to the base system, I'd certainly make this an optional feature, but there are much fatter targets at the moment. -- Brooks
pgpHpnEpjLYXD.pgp
Description: PGP signature
