[lkml]   [2003]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: request_firmware() hotplug interface, third round.
On Thu, May 15, 2003 at 04:38:58PM -0400, Pavel Roskin wrote:
> On Thu, 15 May 2003, Manuel Estrada Sainz wrote:
> > This time, as Greg suggested, it is implemented on top of 'struct
> > class' and 'struct class_device' but the driver interface is the same
> > as last time.
> Nitpicking:
> - Please use max_t, not your own MAX.

I was really wondering why MAX/MIN had not being generalized :)

> - /s/jet/yet/g
> - firmware_loading_show() should be static

All three fixed.

> > - register_firmware can not be implemented without some form of
> > in-kernel firmware caching. And that is not implemented.
> I wrote this private already, but it needs to be said now. It's not
> _caching_ that is needed. What is needed is a filesystem that can be
> populated in the kernel binary.

I don't know that much about initramfs, but how about, firmware images
get included in the initramfs and copied into fwfs during early

I'll call it 'persistence' instead of 'caching' from now on.

And I guess that 'blobfs' would be a much better name than 'fwfs'.
Meaning that it can be used to store any blob.

> Can I use this code to replace broken ACPI table (DSDT) I have in some of
> my systems? Can I use this code to load firmware into my SCSI adapter if
> I need it to access the only disk in the system? Can I use this code to
> program a network interface I'm going to use for root over NFS?

The interface would allow it, but some kind of persistence has to be
there to make it possible.

> > - fwfs could be used for firmware caching behind the scene
> > allowing register_firmware to be implemented and the other
> > uses. I could call it blobfs and make a subdirectory within
> > for firmware purposes.
> I don't understand that, but I admit that it may be the answer to my
> question. Again, "caching" is a wrong word, I believe.

- Rename 'fwfs' into 'blobfs'
- Use it as the persistence mechanism behind request_firmware()
- Use one level of hierarchy within the filesystem:
I don't know if it would really be useful for crypto keys, but it
looked like a good sample :)

request_firmware() would then just search with in


--- Manuel Estrada Sainz <>
------------------------ <> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.129 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site