From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 9 18:16:03 2006 Return-Path: X-Original-To: hackers@freebsd.org Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CCE316A401 for ; Sun, 9 Apr 2006 18:16:03 +0000 (UTC) (envelope-from mwm-keyword-freebsdhackers.102a7e@mired.org) Received: from mired.org (dsl092-153-074.wdc2.dsl.speakeasy.net [66.92.153.74]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D78343D49 for ; Sun, 9 Apr 2006 18:16:02 +0000 (GMT) (envelope-from mwm-keyword-freebsdhackers.102a7e@mired.org) Received: (qmail 97513 invoked by uid 1001); 9 Apr 2006 18:16:01 -0000 Received: by localhost.mired.org (tmda-sendmail, from uid 1001); Sun, 09 Apr 2006 14:16:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17465.20321.174794.576853@bhuda.mired.org> Date: Sun, 9 Apr 2006 14:16:01 -0400 To: Darren Pilgrim In-Reply-To: <4438A0A3.3050600@bitfreak.org> References: <20060407225742.GA21619@odin.ac.hmc.edu> <20060407230247.GH16344@submonkey.net> <4437C9F6.5000008@samsco.org> <17463.65076.117616.563302@bhuda.mired.org> <20060408224140.GA15366@outcold.yadt.co.uk> <17464.17494.251794.271711@bhuda.mired.org> <44385525.8000203@bitfreak.org> <17464.31976.938131.944829@bhuda.mired.org> <4438A0A3.3050600@bitfreak.org> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-Primary-Address: mwm@mired.org X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`; h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ X-Delivery-Agent: TMDA/1.0.3 (Seattle Slew) From: Mike Meyer Cc: hackers@freebsd.org Subject: Re: Using any network interface whatsoever (solution?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2006 18:16:03 -0000 In <4438A0A3.3050600@bitfreak.org>, Darren Pilgrim typed: > Mike Meyer wrote: > > In <44385525.8000203@bitfreak.org>, Darren Pilgrim typed: [Tying names to MAC addresses.] > >> That's far better than trying to remember what's on em0. > > > > That's certainly true. But is there an advantage to tieing the > > PublicLAN name to a MAC address as opposed to em0? > You could test two different drivers on the same hardware and you wouldn't > have to duplicate or modify your ifconfig lines in /etc/rc.conf, just run: Yup, and this is an advantage. On the other hand, if you tie the device name to the slot number (the real goal), you can swap different hardware into that slot without having to modify any configuration information at all. If you tie the name to the MAC address, you always have to change that part of the config. If you tie the name to the current name, then you only have to change it if you change drivers. > Within the currently available capabilities, we get the network interface > equivalent of disk volume labels. Not quite. With volume labels, I can arrange to keep a replicated drive with the same volume label, and can plug it in if the old drive fails without changing a single line of system configuration. Using the MAC address as the key requires that you reconfigure the name mapping (unless you have cards that let you change the MAC address, though I have no idea if those exist for any platform that FreeBSD runs on). > [ Proposed use of PCI addresses instead of MAC addresses. ] > > The real problem with what I proposed is that you have to arrange to > > search config information for things that may not be tied to a pci > > bus. That could get real messy. > Right, it doesn't scale to ISA or USB devices. The prior probably isn't a > big deal these days, but I imagine compatibility with USB devices is fairly > important. >From what Warner Losh posted (thanks for some hard data, Warner), the PCI address isn't fixed, though you're less likely to run into it moving. And Bruce Simpson (thanks Bruce) tells us that the solution I want - names based on slot addresses - is only available on some hardware, at least for now. There's no reason we can't extend your basic solution to handle configuration by either driver/number or MAC address, allowing the user to pick the properties they want for their names. Of course, this doesn't help the OP's problem of wanting to be able to address the sole interface in a system without knowing it's name in advance. Maybe a feature to provide a default name for an interface if one isn't found in the config file would do that. BTW, I'd like to point out that sound cards have the same problem, only they all get the same "driver" name. Worse yet, the numbering can change between reboots (at least, it could on 4.x). http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.