On Tue, Jun 27, 2017 at 12:52 PM, Bjorn Andersson <bjorn.anders...@linaro.org> wrote: > 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: >> > 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.
I'm sorry if I offended you, the goal here was to use an exaggerated example of what anyone could use to draw in firmware into the kernel. >> 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? The model of a best-effort and final-mode. > 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. You get that freedom today. The fallback mechanism *allows* files to be fetched in whatever way possible, by issuing a uevent, its up to userspace to figure out how to gather that and toss it back into the kernel using the sysfs interface. The firemward daemon is nothing but an example *new* daemon which uses a model to address the rootfs / pivot root dilema, as only userspace can know when userspace *is ready*. So its not clear to me yet what your grudge with using firmwared with this new model is exactly. Are you saying you want to *require* the fallback mechanism from the start, so just skipping the direct FS lookup ? That would be a new feature request, and we can certainly consider it, but I'll need Greg to clue me in first on how he'd prefer an API evolution for new features. Luis
