[Take 2] Re: RFC: interface description

[Julian Elischer]

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..