excellent points matt
"There is no working bad source so bad that a binary blob is better" "working bad source should never be replaced by a blob, but only by improved working bad source" "we must never remove working bad source that is in use if the only replacement is a blob" On Thu, Sep 12, 2019 at 1:47 PM Matt B <matthewwbradl...@gmail.com> wrote: > > Greetings all, > > Patrick gregori said: >> >> Mostly chatter on IRC, to be honest. Part of the intent of this mail was to >> surface this more officially. > > It would be helpful to carry over more details when porting discussions from > IRC. It is always good to be specific how something is broken, not just that > the garbage collector is coming. > > Kyösti said: >> >> Since coreboot seems to accept blobs with ease nowadays, the solution to >> keep these platforms can be such that we move AGESA vendorcode to submodule. > > This is one way of handling it, but I don't think it does anything to address > the quality of the code. Out of sight and out of mind, so to speak. > >> We can equally make such quality assurance arguments about FSP2.0, once >> commercial vendor gets something merged, they don't really care how much it >> gets in the way of overall architecture or subsystems evolution. > > As Ron noted: >> >> We kept it relatively the same when AMD was a player in coreboot, but >> they're long gone; time for major surgery? > > I assume that AMD probably doesn't have any plans to revisit 15h if/when they > follow through on porting 17h? :-) > > Patrik said: >> >> This was about surfacing issues like these earlier, to reduce the amount of >> surprise. Having your status update on the C bootblock and CAR migration >> implementation is useful for that, too! > > Is there a single point of reference for this kind of information, to avoid > surprises? > > Ron said: >> >> Is this statement true? >> "There is no source so bad that a binary blob is better" > > Unless this is the trivial case where the blob boots and the code doesn't (or > is otherwise functionally inferior), I would argue that any code can be > compiled into a blob. > Thus, the code is automatically as-good-or-better. :-) > >> If we take that to be true, then what about this: >> "bad source should never be replaced by a blob, but only by better source" > > This is where things begin to come apart. The first part is true based on (1) > but unless someone writes better source, eventually the code breaks and you > enter the trivial case above. > >> "we must never remove source that is in use if the only replacement is a >> blob" > > If the code works (it is in use after all), then refer to (1). Otherwise, > this is the trivial case. > > Once you find yourself in the trivial case, you need to make the decision to > either fix the broken code, or embrace the blob. > > Sincerely, > -Matt > > On Thu, Sep 12, 2019 at 1:36 PM ron minnich <rminn...@gmail.com> wrote: >> >> Interesting discussion! It got me to wondering, having spent a lot of >> time in the V1, V2, and V3 trees the last few months. >> >> Is this statement true? >> "There is no source so bad that a binary blob is better" >> >> If we take that to be true, then what about this: >> "bad source should never be replaced by a blob, but only by better source" >> >> From there: >> "we must never remove source that is in use if the only replacement is a >> blob" >> >> Would that help guide the decision on AGESA? Or is it just more bikeshedding >> :-) >> >> I personally find the AgEsA cOdE quite UgLy, but ... it's code. I >> wonder if it can't be fixed with a few >> initial spatch passes. We kept it relatively the same when AMD was a >> player in coreboot, but they're long >> gone; time for major surgery? >> >> I don't think we want to say "ugly code, nuke it" unless there is >> replacement that is code. >> >> ron >> >> >> >> On Thu, Sep 12, 2019 at 9:46 AM awokd via coreboot >> <coreboot@coreboot.org> wrote: >> > >> > Patrick Georgi via coreboot: >> > > Hi everybody, >> > > >> > > coreboot is shipping AMD's open sourced AGESA for a few generations >> > > as part of its tree. >> > > >> > > Some people advocate dropping the code due to its quality and lack >> > > of maintenance while others are happy with using the code. >> > > >> > > So: to help keep this code alive, we'd need maintainers - people >> > > willing to work through issues, improve the code quality and generally >> > > act as a point of contact if any questions arise. >> > > >> > > One item to start with could be to work through Coverity >> > > issues, where the largest proportion is now AGESA based >> > > after Jacob cleaned up most of the rest of the tree. See >> > > https://scan.coverity.com/projects/coreboot >> > >> > I would like to help out. Is there someone experienced who can mentor me >> > on setting up a streamlined, open-source development environment for >> > Coreboot? I've been using grep and gedit for my hacking needs, but >> > trying to maintain a 5 level deep state table of AGESA code dependencies >> > in my head was a problem. How did Jacob get started and what IDE did he >> > use, for example? >> > >> > > Drivers needs support to not get in the way of later development, >> > > and AGESA is sorely lacking in that department. If you see value >> > > in that code, please step up now, not only when we're looking into >> > > removing that code for good. >> > >> > Which drivers and what support? I see Kyösti Mälkki replied with better >> > questions. Where is the biggest pain point today, i.e. not already being >> > worked on and would return the most value to Coreboot by my work? >> > _______________________________________________ >> > coreboot mailing list -- coreboot@coreboot.org >> > To unsubscribe send an email to coreboot-le...@coreboot.org >> _______________________________________________ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
