I share Kyösti's concerns how this could be compatible to our
code for real hardware targets. Existing platform code relies
heavily on the VID/DID of PCI devices, that are never read with
this approach. So what should it be, should we hide the minimal
scanning option for all boards but those that are confirmed to
be fully compatible? Should we add a big fat warning, that this
is experimental and will break 90% of our ramstage code (and
hence, nobody should complain or even try to fix it)? Should
we remodel all of coreboot so we rely less on PCI and do things
more in a blob-style manner?Without knowing even a coarse plan how to adapt this to exis-
ting hardware support, I really don't see how this is a step
forward. At least a hardware PoC with extensive Linux tests
(not just, it boots) would be nice. Also, if this requires
changes to the OS, do we expect upstream Linux, for instance,
to follow?Hi Nico,
Hello Lean,
While I respect your technical expertise, I cannot fathom your sentiments on this case.
it's not about sentiment, it's about unanswered questions.
Do you mean that every changes in open source should be vigorously validated with most platforms,
No.
and require a coarse plan for implementation?
Yes.
From my understanding, the success and sustainability of open source relies on its openness to encourage and embrace changes no matter how big or small.
This statements makes little sense here because you project it
on the size of a change? So yes, the size of a change doesn't
matter. What is your point?
You should be even more understanding on this as I saw your countless changes everywhere, still we happily accept your inputs even it breaks our codes some times.
With that being said, this patch is providing a forefront idea for us to further improve the flexibility of coreboot. Of course, we can't expect it to be perfect, but anyone can take it and experiment with it and further improving it. I can foresee how it will make our codes to run more dynamically, and it will also eventually push changes to the linux side as well.
It also has the potential to divide coreboot development. If
we don't plan ahead how the platform code should work both with
this option enabled and disabled, we might end up implementing
a lot of things twice... maybe it's just me again, failing to
see that other players have unlimited resources.
I can't make you to change your mind, but i am sure you know what needs to be done if we want coreboot to continue evolves into much greater form.
Of course you can change my mind. You could start by answering
my questions instead of hijacking a technical discussion.
To view, visit change 36221. To unsubscribe, or for help writing mail filters, visit settings.