Trying Eudora 4.3 on Solaris solicits this error
err:winsock:WsControl Unable to open /proc filesystem to determine number of network interfaces!
Looking about in the code WsControl grubs about in the /proc filesystem to get the names of, and count the number of network interfaces. Since /Proc only hosts processes on Solaris this constitutes a linux dependancy we don't need. Studying the ifconfig source gives another possibility instead which look like it may be more portable using ioctl SIOCGIFCONF on an arbitrary IP socket
The return from this call is a structure containing the length of the reply buffer, which seems to contains an array of ifreq structures (one for each interface) which contains among other things the name of the interface. By dividing the size of the buffer by the size of the returned objects we know how many interfaces there are...
Questions Anyone know if this is Is this workable ? Is this workable on linux, (I ask because I don't have linux and don't know linux ioctl implementation details)?
Robert Lunnon wrote:
Looking about in the code WsControl grubs about in the /proc filesystem to get the names of, and count the number of network interfaces. Since /Proc only hosts processes on Solaris this constitutes a linux dependancy we don't need. Studying the ifconfig source gives another possibility instead which look like it may be more portable using ioctl SIOCGIFCONF on an arbitrary IP socket
The return from this call is a structure containing the length of the reply buffer, which seems to contains an array of ifreq structures (one for each interface) which contains among other things the name of the interface. By dividing the size of the buffer by the size of the returned objects we know how many interfaces there are...
Questions Anyone know if this is Is this workable ? Is this workable on linux, (I ask because I don't have linux and don't know linux ioctl implementation details)?
SIOCGIFCONF isn't in the Single Unix Spec, V2, but it does appear to be in Linux. It also appears to be in Irix. Looks like a widely used ioctl.
But note:
http://mail-index.netbsd.org/tech-net/2001/05/09/0001.html http://www.geocrawler.com/archives/3/154/2000/2/0/3362774/ http://www.geocrawler.com/archives/3/495/2000/10/0/4586144/ SIOCGIFCONF is supported by netbsd, but is hard to use gotchas because size of reply larger than expected
http://mail.gnu.org/pipermail/bug-inetutils/2001-January/000055.html glibc supports SIOCGIFCONF, but not for down or virtual interfaces
http://www.cygwin.com/ml/cygwin/2001-03/msg00518.html cygwin supports it (so we can run wine on cygwin on windows :-)
- Dan
On Sat, 8 Sep 2001, Robert Lunnon wrote: [...]
need. Studying the ifconfig source gives another possibility instead which look like it may be more portable using ioctl SIOCGIFCONF on an arbitrary IP socket
[...]
Questions Anyone know if this is Is this workable ? Is this workable on linux, (I ask because I don't have linux and don't know linux ioctl implementation details)?
It's probably workable. Especially since WsControl already uses a number of similar ioctls (SIOCGIFHWADDR, SIOCGIFADDR, ...). But I think we should keep the /proc code around on Linux (though in the worst case we could still get it from CVS). I believe that Linus does not like ioctl's so I would not be surprised if they were to disappear one day...
Anyway, there is something else that would be great. I see very similar code in WsControl in dlls/wsock32 and in WSAIoctl in dlls/winsock: * WSCNTL_GetInterfaceName and WSAIOCTL_GetInterfaceName are very copy/paste alike * same for WSCNTL_GetEntryCount and WSAIOCTL_GetInterfaceCount * WsControl's IP_MIB_ADDRTABLE_ENTRY_ID and WSAIoctl's SIO_GET_INTERFACE_LIST seem to do very similar things
So the idea would be to try to implement WsControl by making appropriate calls to WSAIoctl. This would have the following benefits: * reduced code duplication (especially such non portable code) * it would greatly help me in my winsock header rewrite * which would lead to much cleaner code (removal of the socket hack)
More about this header rewrite. The problem I have is that wsock32 uses both the Unix socket calls (in WsControl for SIOCGIFHWADDR and friends), which means I must include the Unix socket headers, and Winsock specific macros and types, which means I must include the winsock headers. Now, since the new winsock headers don't simply #include the Unix ones to get their stuff this generates conflicts. For instance the Unix bind is cdecl while the one in winsock is stdcall. The current trick is to force the prefixing of all things Winsock with WS_ to avoid conflicts. But then calling from wsock32 to ws2_32 becomes not very practical. I solved it for now using very ugly hacks. But the clean solution is to not use the Unix stuff at all in wsock32. And I believe the only obstacle to that is the current implementation of WsControl.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ La terre est une bêta...
-
Dan Kegel -
Francois Gouget -
Robert Lunnon