[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49B8E6D4.2030702@weinigel.se>
Date: Thu, 12 Mar 2009 11:41:24 +0100
From: Christer Weinigel <christer@...nigel.se>
To: Stephen Hemminger <shemminger@...tta.com>
CC: David Miller <davem@...emloft.net>, s.hauer@...gutronix.de,
yanok@...raft.com, linux-arm-kernel@...ts.arm.linux.org.uk,
netdev@...r.kernel.org, wd@...x.de, dzu@...x.de
Subject: Re: [PATCH] dnet: Dave DNET ethernet controller driver
Stephen Hemminger wrote:
> On Wed, 11 Mar 2009 21:56:06 +0100
> Christer Weinigel <christer@...nigel.se> wrote:
>> It's still a pain to have to do this. Many embedded systems that I have
>> seen have a bootloader which I can't modify to do that, but the
>> bootloader allows me to save the kernel command line into some kind of
>> volatile storage. Så being able to set the MAC address with a:
>>
>> setenv cmdline foo.hwaddr=00:de:ad:be:ef:ed
>>
>> is very nice because it allows me to use a NFS root without having to
>> jump through hoops with initrds an such.
>>
>> Actually, I wish we had a generic way of doing that, so that could set
>> the mac address of any ethernet interface from the kernel command in a
>> nice and supported way.
>
> The problem is that usually users end up with all devices with the
> same address, unless there is some other procedure to hand out addresses
> during configuration. That is why the random_ether_addr is safer.
Random mac addresses, yuk! :-) I'd much rather have something that I
can make "do the right thing" than something I can't. And as I said,
what I've encountered many times is a reference board from some
manufacturer where the following conditions are present:
1. The bootloader can pass a command line to the kernel and it is saved
in non-volatile storage that can be changed from the bootloader
2. I can not modify the bootloader
3. I can modify the Linux kernel
4. The manufacturer has hardcoded a MAC address in the ethernet driver
5. I want to use NFS root to make it easy to develop on the platform
6. We get a second board so the hardcoded MAC addresses collide
In this situation I usually hack a hwaddr module param into the ethernet
driver, so that I can actually make the devices have different, but
stable, MAC addresses. The alternatives are to hardcode the MAC address
into the kernel and run different kernels on different boards, or to
create an initrd with a tools that parses the kernel command line to
extract the MAC address and then do ifconfig eth0 hwaddr $HWADDR, and
then add a DCHP client which gets the NFS root from the DCHP response
and finally mounts the NFS root and switches too it. But I'm lazy so as
I said usually just hack the driver.
/Christer
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists