Messages in this thread | | | Date | Wed, 30 Aug 2006 14:11:51 -0700 (PDT) | From | David Lang <> | Subject | Re: [PATCH] MODULE_FIRMWARE for binary firmware(s) |
| |
On Wed, 30 Aug 2006, Sven Luther wrote:
>> no, at least not in the current kernel. as was mentioned earlier in this >> thread the ipw2200 needs the firmware at initialization, but some others >> don't need it until open. I don't know if it's even possible to re-write >> the driver to do this. > > Oh well, this doesn't explain why it is so, but i suppose you know what you > speak about.
I'm a user, not a developer. I know what is, but not nessasarily why, and I have no idea how bad it would be to change.
>>> If we want to remove it, then we put, not the module, but the firmware >>> itself >>> with some basic userspace to load it on demand in the initramfs, and this >>> is >>> reason enough to create an initramfs. The fact that the builtin device is >>> initialized before the initramfs is loaded seems like a bug to me, since >>> the >>> idea of the initramfs (well, one of them at least), was to initialize it >>> early >>> enough for this kind of things. >> >> this isn't my understanding. > > Indeed, in the initrd era, the ramdisk was initialized too late for this kind > of stuff, but it was one of the features of the initramfs ramdisks to > initialize it earlier, which made firmware loading possible. > >> my understanding is that the kernel fully initializes all built-in drivers, >> then loads userspace and starts running it. > > Well, there is userspace and userspace. > >> that userspace can be on a device that it knows how to read, or it can be >> userspace on initramfs so that you can load additional modules to give you >> access to the hardware that you want to run on. > > Yep, but initramfs is initialized ways earlier than normal userspace. > >> however this is not soon enough to supply the firmware for devices like >> this. > > Are you sure of this ? This is somewhat contrary to what i have heard, and it > sure would make sense to be able to access the initramfs ramdisk much earlier.
I could easily be wrong about this. can someone who really knows weigh in on this?
>>> If on the other side, it is more important to not have an initramfs >>> (because >>> of security issues, or bootloader constraints or what not), then sure, >>> there >>> is not much choice than putting the firmware in the driver or in the kernel >>> directly. >>> >>> But again, the initramfs is just a memory space available at the end of the >>> kernel, and there is no hardware-related constraint to access it which are >>> in >>> any way different from having the firmware linked in together with the >>> kernel, >>> so it is only a matter of organisation of code, as well as taking a >>> decision >>> on the above, and to act accordyingly. >> >> if the firmware needed for any drivers compiled in was appended to the >> kernel the same way that initramfs is, without requireing the other things >> needed to make initrmfs useable I think that would be reasonable (bundling >> them togeather as opposed to embedding the firmware in the kernel). it may >> even be possible to have the firmware as files in a initramfs that contains >> nothing else, and the kernel knows how to read the data directly (without >> the hotplug firmware request userspace stuff) > > Indeed, and it seems to me that exactly this kind of use was indeed considered > when the initramfs infrastructure was designed. Not sure about the latest bit > concerning hotplug though.
this gets back to the question of how early this early userspace is
David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |