From owner-freebsd-arch Wed Aug 9 15:19:19 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id 3E76C37B883 for ; Wed, 9 Aug 2000 15:19:12 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115209>; Thu, 10 Aug 2000 08:19:00 +1000 Content-return: prohibited Date: Thu, 10 Aug 2000 08:18:58 +1000 From: Peter Jeremy Subject: Interface types defined in if_types.h To: arch@FreeBSD.ORG Mail-followup-to: arch@freebsd.org Message-Id: <00Aug10.081900est.115209@border.alcanet.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (This is prompted by a comment by Garrett Wollman in PR kern/19436 - that FreeBSD needs to define a specific interface type for IEEE 802.1q VLANs). /sys/net/if_types.h describes itself as: * Interface types for benefit of parsing media address headers. * This list is derived from the SNMP list of ifTypes, currently * documented in RFC1573, now maintained as: * * ftp.isi.edu/in-notes/iana/assignments/smi-numbers The current version of smi-numbers lists 115 ifTypes that don't appear in if_types.h (including l2vlan (135) for 802.1q). FreeBSD also defines 4 types (IFT_GIF, IFT_PVC, IFT_FAITH and IFT_STF) that don't match IANA assignments. It would seem to be useful to just import the latest ifTypes list, but the way FreeBSD is using IFT_xxx macros does not perfectly map onto the SNMP ifType. Two groups of mismatches are readily apparent: 1) FreeBSD uses a single type (IFT_ETHER) to represent all Ethernet- like interfaces, whilst ifType defines different types for 100baseTX, 100baseFX, 100baseVG, Gigabit Ethernet and 10Mbps Ethernet. 2) IANA define single softwareLoopback (24) and encapsulation (131, tunnel) interfaces. FreeBSD needs to distinguish between different softwareLoopback devices (lo(4), tun(4)[1] and faith(4)) as well as different encapsulation devices (gif(4) and stf(4)). In the former case, it might be possible to separate out all the different Ethernet media types, but this would add a degree of complexity to each ethernet driver (switching between 10Mbps and 100Mbps would entail changing the if_type value, it would also be necessary to distinguish between the various 100Mbps media types - which may or may not be possible, depending on the PHY), for (IMHO) no gain. In the latter case, FreeBSD must be able to distinguish between different pseudo devices. If they were all mapped onto a single if_type, then a different field would be necessary to distinguish them. How to proceed? Should all the ifTypes be imported - with the understanding that some just won't get used. Should we import and use the ifType name/number where if suits us and ignore the rest? How should we distinguish different pseudo devices - just make up numbers and hope we don't clash? [1] tun(4) currently defines itself as IFT_PPP - whilst this is the most common use, there does not appear to be anything in the device that limits it to PPP. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message