From owner-freebsd-current Mon Aug 3 05:56:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA20220 for freebsd-current-outgoing; Mon, 3 Aug 1998 05:56:58 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA20187; Mon, 3 Aug 1998 05:56:46 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.5] (user5.dataplex.net [208.2.87.5]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id HAA17601; Mon, 3 Aug 1998 07:56:35 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <4990.902145196@gjp.erols.com> References: Your message of "Mon, 03 Aug 1998 13:39:15 +0200." <19980803133915.52291@deepo.prosa.dk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 3 Aug 1998 07:56:05 -0500 To: "Gary Palmer" From: Richard Wackerbarth Subject: Re: Ethernet interface names Cc: freebsd-current@FreeBSD.ORG, regnauld@deepo.prosa.dk Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Philippe Regnauld wrote in message ID ><19980803133915.52291@deepo.prosa.dk>: >> The advantage would be that you could pull out a dead card, plug >> a new (not necessarily of the same model), and there woudln't >> be any need to edit rc.conf, rc.firewall, etc... > >Thats assuming that the card is of the same bus type. If you replace an ISA >card with a PCI card, you will probably end up with a different probe order, Probe order creates a real problem. I can uniquely identify the interfaces by ethernet MAC. I still have to make assumptions about which "new" device is replacing which "old" one. If two change at the same time ... (Anyone got a paddle?) >and hence the exact problems you highlight above. If you could do device >numbering persistance like solaris does, so that devices don't change numbers >over a reboot (just a reboot -r), then I think the `eth' scheme may work. Persistance can be accomplished by using a database (implemented in shell variables) that links {kernel device id (ed0) <==> ethernet MAC} to get around the probe ordering and {ethernet MAC <==> logical interface (eth7)} Then you can write the "rules" using the logical interface. However, this doesn't solve the "replaced hardware" problem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message