I'd consider ioctl for that. It seems that's quite rare when uniq etheraddr
needed very early in kernel life.

	Andrey

On Thu, Aug 22, 2002 at 08:21:11AM +0200, Martin Husemann wrote:
> While investigating a bridge problem on my sparc with dual hme card, I had
> the desire to have all four hmes to acquire different/unique MACs. There is
> the PROM variable local-mac-address? that I thought would controll this, but
> changing that to true did not make any difference.
> 
> So I added a hack to the myetheraddr fuction:
> 
> ---8<---
> RCS file: /cvsroot/syssrc/sys/arch/sparc/sparc/clock.c,v
> retrieving revision 1.89
> diff -c -u -r1.89 clock.c
> --- clock.c	2002/05/02 13:01:45	1.89
> +++ clock.c	2002/08/22 06:15:38
> @@ -152,6 +152,7 @@
>  myetheraddr(cp)
>  	u_char *cp;
>  {
> +	static int count = 0;
>  	struct idprom *idp = idprom;
>  
>  	cp[0] = idp->id_ether[0];
> @@ -159,7 +160,7 @@
>  	cp[2] = idp->id_ether[2];
>  	cp[3] = idp->id_ether[3];
>  	cp[4] = idp->id_ether[4];
> -	cp[5] = idp->id_ether[5];
> +	cp[5] = idp->id_ether[5] + count++;
>  }
>  
>  void
> --->8---
> 
> which worked fine for me.
> 
> I think having to hack source for this admin decision is not the right way.
> 
> So the question:
> 
> Should this (or similar) code be commited?
> Should it be active
> 
>  - always
>  - depending on an option (SPARC_USE_UNIQUE_MACS ?)
>  - depending on the value of OFs "local-mac-address?" 
> 
> ?
> 
> Martin