Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Apr 2014 17:23:47 +0000
From:      "Bjoern A. Zeeb" <bz@FreeBSD.org>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r264646 - head/sys/dev/netfpga10g/nf10bmac
Message-ID:  <E14B470F-CF7C-43E7-B7E6-8A89CC9C7286@FreeBSD.org>
In-Reply-To: <1397831317.1124.301.camel@revolution.hippie.lan>
References:  <201404181421.s3IELAH0082972@svn.freebsd.org> <1397831317.1124.301.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

On 18 Apr 2014, at 14:28 , Ian Lepore <ian@FreeBSD.org> wrote:

> On Fri, 2014-04-18 at 14:21 +0000, Bjoern A. Zeeb wrote:
>> Author: bz
>> Date: Fri Apr 18 14:21:10 2014
>> New Revision: 264646
>> URL: http://svnweb.freebsd.org/changeset/base/264646
>>=20
>> Log:
>>  Now that I figured out where the ethernet addresses come from
>>  on NetFPGA-10G, assign one to the interface by default in a very
>>  similar way.
>>=20
>>  MFC after:		6 days
>>  X-Easter-Egg-Hunt:	yes
>>=20
>> Modified:
>>  head/sys/dev/netfpga10g/nf10bmac/if_nf10bmac.c
>>=20
>> Modified: head/sys/dev/netfpga10g/nf10bmac/if_nf10bmac.c
>> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>> --- head/sys/dev/netfpga10g/nf10bmac/if_nf10bmac.c	Fri Apr 18 =
12:51:30 2014	(r264645)
>> +++ head/sys/dev/netfpga10g/nf10bmac/if_nf10bmac.c	Fri Apr 18 =
14:21:10 2014	(r264646)
>> @@ -446,7 +446,25 @@ static int
>> nf10bmac_reset(struct nf10bmac_softc *sc)
>> {
>>=20
>> -	/* Currently we cannot do anything. */
>> +	/*
>> +	 * If we do not have an ether address set, initialize to the =
same
>> +	 * OUI as NetFPGA-10G Linux driver does (which luckily seems
>> +	 * unallocated).  We just change the NIC specific part from
>> +	 * the slightly long "\0NF10C0" to "\0NFBSD".
>> +	 * Oh and we keep the way of setting it from a string as they =
do.
>> +	 * It's an amazing way to hide it.
>> +	 * XXX-BZ If NetFPGA gets their own OUI we should fix this.
>> +	 */
>> +	if (sc->nf10bmac_eth_addr[0] =3D=3D 0x00 &&
>> +	    sc->nf10bmac_eth_addr[1] =3D=3D 0x00 &&
>> +	    sc->nf10bmac_eth_addr[2] =3D=3D 0x00 &&
>> +	    sc->nf10bmac_eth_addr[3] =3D=3D 0x00 &&
>> +	    sc->nf10bmac_eth_addr[4] =3D=3D 0x00 &&
>> +	    sc->nf10bmac_eth_addr[5] =3D=3D 0x00) {
>> +		memcpy(&sc->nf10bmac_eth_addr, "\0NFBSD", =
ETHER_ADDR_LEN);
>> +		sc->nf10bmac_eth_addr[5] +=3D sc->nf10bmac_unit;
>> +	}
>> +
>> 	return (0);
>> }
>>=20
>>=20
>=20
> For other drivers/socs where we need to cook up an address on the fly,
> we've used "bsd" as the OUI and a 24-bit random for the low order.
> Aside from the nice aesthetic, 'bsd' has the "locally administered" =
bit
> set and thus is g'teed to not clash with any globally assigned OUI.

This is, as the comment, the commit message, and the XXX-BZ indicates, =
to be consistent with that platform.  The change is only to not conflict =
with the host driver to avoid duplicate ethernet addresses when host =
PCI/DMA interfaces, and the =93inside=94 PIO interfaces all talk to each =
other.

If I=92d do this another way, I=92d (a) get a tiny slice from the =
official FreeBSD OUI and (b) put some random bits on the NIC part + the =
unit number.


And, as we have learnt elsewhere, sys/net-admins are not always happy if =
you set the locally administered bit by default, as it=92s them to =
assign the addresses and not the user.  It=92s a game you cannot =
globally win.  This is about providing a =93matching=94 default for the =
environment, and that=92s why it sticks with what the platform is doing =
for now.

/bz

=97=20
Bjoern A. Zeeb             "Come on. Learn, goddamn it.", WarGames, 1983




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E14B470F-CF7C-43E7-B7E6-8A89CC9C7286>