On Tue 27 Jun 12:08 PDT 2017, Luis R. Rodriguez wrote: > On Tue, Jun 27, 2017 at 11:59:15AM -0700, Bjorn Andersson wrote: > > On Tue 27 Jun 11:03 PDT 2017, Luis R. Rodriguez wrote: > > [..] > > > Let's consider a crazy case where the uevent gets triggered, and > > > userspace goes > > > and signals Elon Musk somehow to transmit the needed firmware from Mars > > > through > > > a serial satellite link to earth, and somehow someday the device is > > > finally > > > ready to upload firmware from userspace. Once Elon's firmware lands home, > > > we > > > know all needed firmware has arrived so anything missing we can > > > acknowledge now > > > as missing, so we upload what we can and kick firmward into final-mode to > > > tell > > > the kernel we know we're really ready and any pending things will have to > > > be > > > given up. > > > > > > This would prove the custom fallback crap was also never needed. > > > > > > > Are you saying that each kernel driver should be written so that it will > > either do direct loading or use firmwared? > > Hell No! You can fork firmwared or use whatever the hell bin-foo you want. > Even if its proprietary and glued with evil rainbow unicorns on it. The dual > mode, best-effort mode and final-mode devices it implemented are key to what > you want to mimic as an example to achieve the goal in question. >
I'm sorry but your language is totally inappropriate and the reason why I tend to stay away from firmware-related discussions. > Please give that thought / architecture solution a spin and let me know if > it suffices for your needs. > Which solution do you refer to here? But as I said, in my view, the decision of making the kernel depend on a user space firmware loading mechanism or direct loading should be that of the system designer - not the kernel. Regards, Bjorn
