Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)

[David Lang <dlang@digitalinsight.com>]

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/