netdev - Re: [PATCH] dnet: Dave DNET ethernet controller driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49B91A7B.7050303@weinigel.se>
Date:	Thu, 12 Mar 2009 15:21:47 +0100
From:	Christer Weinigel <christer@...nigel.se>
To:	David Miller <davem@...emloft.net>
CC:	shemminger@...tta.com, 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

David Miller wrote:
> From: Christer Weinigel <christer@...nigel.se>
> Date: Thu, 12 Mar 2009 11:41:24 +0100
> 
>> 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
> 
> This is getting rediculious.

Yes, ridiculous in the complexity of the workarounds for not having a 
generic way to set the mac address from the command line.  :-/

> If you can modify the kernel, you can have the kernel look in the
> non-volatile storage for the MAC address and export that information
> to the ethernet driver.

Which means that the non-volatile storage must be available through a 
Linux driver before the MAC address is set.  AFAIK there is no guarantee 
that the MTD layer will be ready to use by that time.  And that is 
assuming that there actually is a MTD driver available, usually when I 
work on a Linux port for a reference board, the first thing I do is to 
get a NFS root up and running, then I can put a have a complete Debian 
system with all nice debugging tools available.  When I have that up and 
running I start porting the other drivers, such as the MTD driver.

Also, I don't really want to spend time on reverse engineering some 
random non-volatile storage format, that's quite fragile.

> Or, you can parse the command line in your platform specific code
> and program the MAC address into the chip.

Which is actually what I'm doing, except that it's easier to hack that 
into the ethernet driver each time it is needed.

> In fact there are many reasonable ways to solve the problem in
> your scenerio, and none of them require device driver command
> line option handler.

Yes, that why I'd want that in a generic piece of code instead of having 
to hack it into each device driver.  Would a generic command line 
option, something like "ethaddrs=eth0=00:de:ad:be:ef:01" which assigns 
addresses to network cards be acceptable?

Next time I have to port something to an embedded platform with this 
kind of problem, I might try to do something more generic instead of the 
simple hack I usually do now.

   /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