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 vendorcode/ ? 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 indiscriminately. 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 mail was to surface this more officially. > AGESA may reach C_ENVIRONMENT_BOOTBLOCK by the time of the next > release and is already at CAR_GLOBAL_MIGRATION=n. Well, that's good news! > The timeframe for dropping entire platforms has previously > 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 vendorcode > like tomorrow. I'm sorry to have made that impression. That's definitely not what I was proposing. Patrick -- 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
signature.asc
Description: PGP signature
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
