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 for Android: free password hash cracker in your pocket

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

Message-ID: <49B960AE.6050502@weinigel.se>
Date:	Thu, 12 Mar 2009 20:21:18 +0100
From:	Christer Weinigel <christer@...nigel.se>
To:	Christer Weinigel <christer@...nigel.se>,
	Jamie Lokier <jamie@...reable.org>,
	David Miller <davem@...emloft.net>, nhorman@...driver.com,
	shemminger@...tta.com, 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

Sascha Hauer wrote:
>> That would be a very worthwhile project actually.  Create a package that  
>> uses klibc, does BOOTP/DCHP/NFS and parses the the ip=foo,bar options  
>> the same way the kernel does so that we can finally get rid of the in  
>> kernel stuff.
> 
> Great, but how does this help in setting the MAC address? This would
> just move this exact discussion to the dracut or whatever mailing list,
> but we would still be searching for a generic way to say
> eth0addr=00:01:02:03:04:05 and I bet the arguments stay the same.

Alternate answers:

a) It wouldn't.  But that doesn't stop me from liking the idea of 
actually having a working initrd/initramfs that people can build on.

b) It would.  With an easy to use initrd/initramfs infrastructure it 
would be trivial to add a small script that parses /proc/cmdline and 
runs "ifconfig eth0 hwaddr $FOO" based on it.

c) It would.  When the initrd/initramfs runs, it has access to all the 
normal device driver, so reading the first block of flash and parsing 
the non-volatile data (assuming there is a mts device driver and that 
the format is known) and then running ifconfig eth0 hwaddr is also much 
easier.

And personally, yes, if there was a working initrd+dhcp+nfs combination 
that doesn't require significantly more memory than the in kernel one, 
of course I would use it.  And that's what DaveM is suggesting, to keep 
it out of the kernel and move it to user space where it really belongs.

Short therm I'd still like to have the more generic thing in the kernel 
tough.

   /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