From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127545 invoked by alias); 18 Jun 2018 17:17:56 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 127535 invoked by uid 89); 18 Jun 2018 17:17:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=unusual X-HELO: mail-qk0-f196.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oUci9Go7243443h6UeF30yFOfrCZwZe10/zopfPP1bY=; b=oi1v8aohchVaJd7jweMwZrPD52XikitiikCszbwo2GHcR9lMMXZ4lo3QnNZyGIsCQo MeVrXacIdSlk+whAFJY9tSTZcAbFyF5UCLSuKljl3hGEqohwQs7eCxnY74+eMSssoc32 wTYDKJwrFZNaS8irU5zua2x+ScfusncUxfjS6qFYFz+ufgBL3W11E35o08SoEctRsNKy ioKMoqlE9B4yr01qdevSWXkN277E0acAImXrz7hgW3Sw6kkoas9Wmr8BJcznw96YV1Ym NGItLax2IROAl/io3RJwUa/nXqzXCqKV/3omFgMSk09FSFalgi+YhxZuCJgx6hqNmWkP Uoww== X-Gm-Message-State: APt69E306k5xc6QcyRUC8+fTlfor56o5eyGujpF+5KhHMyxUtZ0Uanho Gfs9HjdmSN15JqoHZ09LjaLwDGQ47Tg= X-Google-Smtp-Source: ADUXVKLpu/UzMSa9X+2RTkz73P1mudsNWcWrREPK737W2VT50PrautaFq9GAqWW149cuLSupSVCAtg== X-Received: by 2002:a37:9286:: with SMTP id u128-v6mr10472458qkd.29.1529342273129; Mon, 18 Jun 2018 10:17:53 -0700 (PDT) Subject: Re: [PATCH] Linux: Implement opensock using Netlink sockets To: Florian Weimer Cc: libc-alpha@sourceware.org References: <20180618105015.5E8B340292859@oldenburg.str.redhat.com> <4e69cf5f-309f-007b-bc11-397e831566bd@linaro.org> <87a7rsuim7.fsf@mid.deneb.enyo.de> From: Adhemerval Zanella Openpgp: preference=signencrypt Message-ID: Date: Mon, 18 Jun 2018 17:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <87a7rsuim7.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-06/txt/msg00506.txt.bz2 On 18/06/2018 14:09, Florian Weimer wrote: > * Adhemerval Zanella: > >>> Ahh, it's been fixed since then.  Netlink sockets were one of the >>> few which did not perform ENOIOCTLCMD fallback.  This was changed in >>> kernel 4.6: >>> >>> commit 025c68186e07afaededa84143f1a22f273cd3f67 >>> Author: David Decotigny >>> Date:   Mon Mar 21 10:15:35 2016 -0700 >>> >>>     netlink: add support for NIC driver ioctls >>> >>>     By returning -ENOIOCTLCMD, sock_do_ioctl() falls back to calling >>>     dev_ioctl(), which provides support for NIC driver ioctls, which >>>     includes ethtool support. This is similar to the way ioctls are >>>     handled in udp.c or tcp.c. >>> >>>     This removes the requirement that ethtool for example be tied to the >>>     support of a specific L3 protocol (ethtool uses an AF_INET socket >>>     today). >>> >>> It's unfortunate that it took that long to make this change. >>> >>> Thanks, >>> Florian >> >> Indeed, so I think we will need the fallback options (maybe we can restrict >> to some options). > > The real question is whether it is important to avoid module loading. > If we could just try > > AF_NETLINK > AF_UNIX > AF_INET > AF_INET6 > > in this order, irrespective of the module load status, the code would > already be much, much simpler. > I think it should cover the expected kernel support (it would be unusual to use the getifaddr functions with a kernel without tcpip support). The issues is we will need to ensure the returned socket works with SIOCGIFNAME (maybe by issuing a ioctl to make it sure).