[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thinking about siocgifconf and friends
From: |
Alain Magloire |
Subject: |
Re: thinking about siocgifconf and friends |
Date: |
Fri, 12 Jan 2001 20:57:23 -0500 (EST) |
>
> Hi,
>
> I think I want to solely use if_nameindex, and wrap it up in libinetutils
> for systems which don't have it.
>
> Systems which have SIOCGIFNUM, SIOCGIFCONF and SIOCGIFINDEX are ideal.
> Systems which don't have SIOCGIFNUM are taken care of by doubling the buffer
> and retrying the SIOCGIFCONF call until there is no truncation.
Agreed, this is a real burden. I think you could check if the last len return
did not change to see if its over, vaguely remember this in one of the
R. W. Stevens book but I would have to check.
Does Posix.1g came up with an API for those things ?
> Systems which don't have SIOCGIFINDEX will get either get a dummy index number
> assigned by libinetutils wrapper, but applications should not display this
> to the user if their life span is short. It is only guaranteed to be
> constant for the time the task runs, of course.
- I vaguely remember that SIOCGIFCONF only work with Ethernet network
meaning if you have PPP, DHCP, the "ppp0" will not show or something
can not recall. But I not certain, it was something I read on the web.
- Some socketaddr does carry a len, sa_len, some don't, very annoying.
- I think SIOCGIFCONF should work for virtual interface too .. not sure
if yes do you take to account in your scheme that an interface can have
multiple IP numbers.
> (For example, a program showing a menu with all interfaces and let the user
> pick can make use of the index number. A program like ifconfig should not
> accept something like ifconfig --interface-by-index 3, because the user can
> not make any assumptions for the numbering, even if he run ifconfig before
> and it reported "3" for this interface).
All I have to say is .. hmmm ... But I'm too confuse about IMAP protocol
in GNU mailutils to thing that one straight.
> There will be the need of some flag for the applications to tell them if
> case 1/2 or 3 applies.
>
> If I am missing something that makes the above approach unfeasible, please
> let me know.
>
> BTW, something we really, really need is some inetutils.h header file of
> some sort with prototypes et al. I'd think that Jeff can cook up the autoconf
> magic here that is necessary to make this work correctly.
The problem is that we do not want to define all the functions, they
may conflict for example;
char *strdup (const char*);
Look right but conflict with the system headers. In inetutils.h should
be *our* functions not the prototypes of the functions we can not find
on the system.
--
au revoir, alain
----
Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!