netdev - Re: bnx2 dirver's firmware images

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]

Date:	Tue, 18 Sep 2007 12:27:04 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	David Miller <davem@...emloft.net>
CC:	mchan@...adcom.com, vda.linux@...glemail.com,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: bnx2 dirver's firmware images

David Miller wrote:
> From: "H. Peter Anvin" <hpa@...or.com>
> Date: Tue, 18 Sep 2007 11:41:34 -0700
> 
>> David Miller wrote:
>>> I don't like it because it means people have to setup full initrd's
>>> in order to do network booting with such network cards.
>>>
>> klibc could help with that, if there is interest in exploring that
>> avenue again.
> 
> I appreciate the effort you put into klibc and the offer to
> make initrd's easier to build.
>
> But the point is that the initrd shouldn't be necessary in the first
> place.  There becomes zero point in building these drivers statically
> into the kernel, which many of us do specifically to avoid module
> loading, initrds, and all that fuss.  Because the driver is totally
> crippled even though it's been fully built into the main kernel image.
> 
> I mean, it's so incredibly stupid and makes kernel development that
> much more difficult.
> 
> Every new dependency, be it requiring initrd or something else,
> is one more barrier added to kernel development.
> 
> I really pine for the days where everything was so simple, and initrd
> and modules were the odd ball cases, most developers built everything
> into their kernel image.

Well, what I was referring to here, of course, was the initramfs
integrated in the kernel image, so it all comes out of the kernel build
tree and produces a single bootable image.  The fact that part of it
contains userspace code is in that way invisible.

That was kind of the point here, and the only reason for pushing klibc
into the kernel build tree at all.  Under the "distros use external
initrd anyway" school of thought, whatever libc used for that can be
external anyway.

	-hpa
-
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