From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Patch for network-interface-{list,info} Date: 18 Nov 2003 10:46:33 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87ad6w2hm6.fsf@Dora.local.> <8765hi2pl7.fsf@Dora.local.> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1069145437 16213 80.91.224.253 (18 Nov 2003 08:50:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2003 08:50:37 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Nov 18 09:50:34 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AM1ZC-0008OZ-00 for ; Tue, 18 Nov 2003 09:50:34 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AM1ZC-00055q-00 for ; Tue, 18 Nov 2003 09:50:34 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AM2UF-0000ws-CV for emacs-devel@quimby.gnus.org; Tue, 18 Nov 2003 04:49:31 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AM2TX-0000sr-1x for emacs-devel@gnu.org; Tue, 18 Nov 2003 04:48:47 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AM2Sz-0000WX-Kk for emacs-devel@gnu.org; Tue, 18 Nov 2003 04:48:44 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.24) id 1AM2Sy-0000TQ-Td for emacs-devel@gnu.org; Tue, 18 Nov 2003 04:48:13 -0500 Original-Received: (qmail 46906 invoked from network); 18 Nov 2003 08:46:45 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 18 Nov 2003 08:46:45 -0000 Original-To: Alex Plotnick In-Reply-To: <8765hi2pl7.fsf@Dora.local.> Original-Lines: 63 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17881 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17881 Alex Plotnick writes: > storm@cua.dk (Kim F. Storm) writes: > > > It's definitely a cleaner interface, yes, and maybe it is as widely > > available as SIOCGIFCONF these days...? > > I agree that it's much cleaner. As far as I know, the free BSDs all have > it, and it's in glibc on GNU/Linux. Irix doesn't have it; I don't know > about Solaris. > > > But in any case, since network-interface-list is a new addition in CVS > > emacs, I think it would be alright for us to restrict its availability > > to those systems which do support getifaddrs. > > This seems reasonable to me. If anyone knows of a good reason why this is > not an acceptable course of action, please let me know. We really want emacs to be as portable as possible, and that includes the Emacs Lisp code. So if you say that getifaddrs is not really as widely available as SIOCGIFCONF -- and getifaddrs has its own problems with portability (as you indicate below) -- I think we should keep SIOCGIFCONF as a fallback -- at least for the moment. Of course, the version based on SIOCGIFCONF will also have to be reworked to return the additional information like the getifaddrs version will do. > > > How does getifaddrs return the hw address? In ifaddr->ifa_data ? > > Is that portable? If not, maybe it could use SIOCGIFHWADDR as > > a fallback. > > getifaddrs() actually returns *two* entries for each interface: one > describes the layer-3 address, and the other the link-layer address. Which > one is which is determined by examining the sa_family of the given sockaddr > (ifa_addr). On BSD, this sockaddr is actually a struct sockaddr_dl and has > family AF_LINK, whereas on GNU/Linux it's an AF_PACKET and is described by > a struct sockaddr_ll. There's no need to muck around with the raw ifa_data > field. This doesn't sound very portable to me. Is there any way to know how a given getifaddrs behave in this respect? > > > If you want to modify network-interface-list and -info according to > > the suggestions above, I would appreciate it. > > I'll send a patch in the next day or two. Good, thanks. > > > Are you interested in signing papers for your changes? > > This is no problem. If the relevant party contacts me privately via email, > I'll be happy to provide a mailing address for whatever paperwork is > necessary. Richard? -- Kim F. Storm http://www.cua.dk