Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
My things-to-worry-about folder still has 244 entries. Nobody
seems to care much. Poor me.
-- Andrew Morton
This is the kind of crap that happens when drivers in the kernel
are not self contained, and need "external stuff" to work properly.
It means that simple things like NFS root over the device do not
work in a straightforward, simple, and elegant manner.
-- David MillerI am likely to always take the position that device firmware belongs in the kernel proper, not via these userland and filesystem loading mechanism, none of which may be even _available_ when we first need to get the device going. (Log in to post comments)
David Miller vs. firmware Posted Jun 10, 2005 14:17 UTC (Fri) by chip (subscriber, #8258) [Link] Eventually, initrd will get too big, but for now, it can hold whatever firmware is needed. (Right?)
David Miller vs. firmware Posted Jun 16, 2005 16:13 UTC (Thu) by landley (guest, #6789) [Link] How will initramfs be too big if stuff is in there instead of in the kernel binary image? Isn't the alternative (that stuff being in the kernel binary image) just as big?
David Miller vs. firmware Posted Jun 18, 2005 12:23 UTC (Sat) by k8to (subscriber, #15413) [Link] Well, tools + scripts + firmware takes up more space than firmware, but I'm doubting this is going to become a limitation real soon.
Quotes of the week Posted Jun 17, 2005 14:55 UTC (Fri) by jonsmirl (guest, #7874) [Link] It is a giagantic pain tracking the firmware when it is out of tree. You need to figure out where it, have some scheme to retrieve it, build it into your boot system and make sure that the version matches what the driver expects. This is a great step forward in making life easier for users.
Obviously I'm not one of those people who think it is my right to have the source code for the microcode being loaded into my device. Does Debian skip CPU microcode updates because Intel won't give them the source?
|
|||||||||||||