Date: Mon, 3 Aug 1998 07:56:05 -0500 From: Richard Wackerbarth <rkw@dataplex.net> To: "Gary Palmer" <gpalmer@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG, regnauld@deepo.prosa.dk Subject: Re: Ethernet interface names Message-ID: <l03110700b1eb5f9c52f8@[208.2.87.5]> In-Reply-To: <4990.902145196@gjp.erols.com> References: Your message of "Mon, 03 Aug 1998 13:39:15 %2B0200." <19980803133915.52291@deepo.prosa.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03110700b1eb5f9c52f8>