On Mon, Aug 29, 2011 at 08:16:53PM +0200, Peter Zijlstra wrote:
> On Mon, 2011-08-29 at 20:09 +0200, Peter Zijlstra wrote:
> > > That would suck, suppose this radeon thing is the only console you've
> > > got (ppc64/sparc64 don't have text mode iirc) and userspace doesn't come
> > > up?
> >
> > Same is true for NICs and netconsole of course. Not being able to stick
> > blobs into the kernel image would so suck.
>
> NICs and nfsroot, I suppose can you use an initrd over tftp as well, but
> really, what's the point of an in-kernel nfsroot if you need initrd
> crap.
Damn,
just when I thought that the lofty goal of Linux distancing itself from
firmware crap is within reach, you came up with all those real-life,
nagging examples.
So here's the whole deal IMHO:
* driver =m and request_firmware() works fine - you only need the blobs
in the right place.
* driver =y and request_firmware() should be fixed in all cases where
driver can wait.
Your use cases could probably be addressed by supplying firmware blobs
from the bootloader. We had this talk already concerning CPU microcode
updates and how the current method is to load CPU ucode when the module
gets loaded, which might be too late for some obscure (and not so
obscure) cases.
So, hypothetically speaking, hpa suggested then that we could pass
firmware blobs over the linked list setup_data thing in the real-mode
kernel header and parse_setup_data() can look at them and map them
somewhere later for the driver to find. This should be doable because
you're only gonna need a handful of blobs for CPU ucode, network and GPU
if the last is compiled in.
I wanted to take a serious look at that for the ucode loading, maybe I
should try to shuffle some time for it...
--
Regards/Gruss,
Boris.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
