On Thu, Sep 12, 2019 at 07:20:49PM +0300, Kyösti Mälkki wrote:
Would "some people" or these
"advocates" be willing to elaborate?
I CC'd Nico and Martin because I
seem to remember that we talked
about AGESA (and its quality and/or life cycle). Nico, for example,
seems to advocate scrapping AGESA to replace it with a rewrite ;-)
I would say >50% of our MAINTAINERS file is just
bogus when it comes
to working through issues.
Which is something we're trying to improve.
As an active topic, I don't see
anybody at Intel willing to discuss the topic of how hiding PCI
devices may brake PCI compliance and generally several assumptions in
coreboot PCI subsystem.
It's unlikely that they'll find your request hidden
in this thread,
which is about something very much outside their domain, so please
start a discussion separately and maybe Cc the people closest to
being maintainers for that part of the code (e.g. affected SoC)?
Do you want to extend this with c) coverity scan over
Sorry if I wasn't as clear on this as I wanted to be: I'm not
saying that "it's ugly in Coverity means we'll drop the code", but
we have a couple of folks complaining about AGESA code quality like
all. the. time (e.g. Nico?), and during Jacob's GSoC there was some
talk about how it's unclear how long that code will remain in the
tree anyway (I think Martin can chime in on this).
As I'm working through Coverity, that was brought back to my attention
and I thought about thinking about that. Also, if somebody wants
to step up as maintainer, Coverity provides a pretty good set of
bite-sized tasks that walk you through the code area of interest
We said to leave vendorcode alone, but that was under the assumption
that it's maintained from some upstream source. Our AGESA sources
quite obviously aren't, so why not open them up to development
(including clean up) some more?
Reference to some already existing gerrit comments or
mailing list posts
would be nice.
Mostly chatter on IRC, to be honest. Part of the intent of this
was to surface this more officially.
AGESA may reach C_ENVIRONMENT_BOOTBLOCK by the time of
release and is already at CAR_GLOBAL_MIGRATION=n.
Well, that's good news!
The timeframe for dropping entire platforms has
been couple releases or couple years,
No change intended here. I mostly wanted to
avoid bringing this up
formally just days before the intended removal (from feedback on the
removals in 4.10, people don't seem to notice out various deprecation
notices but only when stuff is gone).
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!
you are making it sound like you want to drop AGESA
I'm sorry to have made that impression. That's definitely
not what I was
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado