coreboot leadership meeting notes are now public:
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...
Anyone interested in joining the leadership meetings in the future can check the calendar on the coreboot website for call-in information.
------------------------------------------------------------ 22 May 2019 Attendees: PatrickG, Werner, Jay Talbott, Martin, Matt DeVillier, Felix Held, Stefan, Kerry Brown, Ron, Philipp, Dhendricks
Topics: * Results of polls (See https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/OWHSS...) * Implement this after the 4.10 release. * Copyrights * Winner in poll: Create an authors file and remove all existing copyright lines * Discuss with SFC - need to figure out if there are any issues with removing copyright lines. * Characters per line * Winner in poll: 96 character lines. * Will reformat in conjunction with the clang-format * Update the contributor guidelines now, but the tree will lag behind for a while longer * Reformatting with clang-format * Winner in poll: Submitters should run clang-format before submitting a patch and it should be rejected in gerrit if it’s not formatted properly with an error telling them how to format it. * Will reformat the tree on a directory-by-directory basis and enforcement will start as directories are reformatted * Need to finalize clang-format options before we start * src/vendorcode will not be reformatted * Number of people voting varied by question 59/68/61
* coreboot contributor expectations * This will be a guideline for now - No significant penalties at this point. * Code should be maintained as long as a chip/platform is being sold? * Stefan feels that we shouldn’t have different guidelines for individuals and companies. * David feels like rejecting patches is going to stifle progress. * We will discuss this further on the mailing list. * If we make guidelines, the community will likely take these as rules and reject patches if they aren’t followed. * No decision made for now, review again next week.
* Shall we add a CREDITS file a la Linux for people who contributed but are no longer active? * How is this different than the authors file? * Credits is for people who are no longer involved in the project. This is for people who authored code that is no longer in the master branch. * Can we make this part of the AUTHORS file? Or does it need to be its own thing? * Decision: Put the credits list in the Authors file.
* Can we adopt on principle removing all cpp guards on protos? * Add cleanup task - remove guards specifically around prototypes? * Having the prototypes outside of guards turns a compile time error into a linker error. * We should be more strict about how we define our blocks’ APIs. We should make better definitions about what each block exports. Document these better, and maybe be more strict about what code consumes which function. * Keep header file guards * No decision made for now
* Release - still plan releasing on May 28th. * Need to update release notes. Pad at https://piratenpad.de/p/coreboot4.10-release-checklist
* Issue tracker: * Philipp: Can we replace redmine? * Stephan: Not with bugzilla. We've already tried bugzilla and trac. * Monorail? Only runs on app engine. * Some people are not sure how to address issues on current bugtracker as there’s no gerrit integration. * There is a Gerrit redmine plugin, which might help * Use github as our bugtracker? * This would probably encourage other github use like merge-requests, which we don’t want. * “its-redmine” (or other plug-in) for gerrit-redmine integration? https://github.com/cyrilix/its-redmine
------------------------------------------------------------ 8 May 2019 Attendees: PatrickG, Martin, Matt Devo, Felix Held, Stefan, Marc Jones, Philipp, PatrickR, David Hendricks
Topics: * People are trying to subscribe to the coreboot security mailing list. Who should be on that list (and what criteria decide this)? * We don’t want this to be widely available to the public in case a significant security issue is announced. We want to make sure we can fix it before it’s announced to the public. * There’s currently nothing on the list, maybe because out code is great, and maybe because the list isn’t widely known. * Who should have access? * Currently Stefan & Patrick are the only 2 on the list * Martin: people who can merge code to coreboot? * Should we turn this into an alias instead of a mailing list? * AI:Patrick Add the security list to the website and announce on the mailing list. * Decision: Keep as a list so that there’s an archive * Decision: Keep the Stefan & Patrick as the only people on the list for now * Decision: Bring this up again once there is activity on security@ and we know better what to do.
* Community votes * Decision: The poll will be set up to start on Tuesday (May 14), running until the next leadership meeting on May 22nd. * 4.10 process (pgeorgi hasn’t announced anything yet) * AI:Patrick will announce today * GSoC * 4 students have been accepted * All have arrived on the mailing list or IRC * Finding a leadership group replacement for Marc * David Hendricks is the only one who responded to the self nomination. * Werner supports David to replace Marc (as claimed by Martin) * Stefan supports David * Marc also supports David * Decision: David Hendricks is voted in to replace Marc * David: “Thank you” * AI: Martin will notify the SFC (Done) * Martin to push picasso documentation to coreboot * Writing now, Need to get permission from AMD before publishing. * OSF Hackathon (June, Bochum) * Lunch will be served there, dinner is Hunt-Your-Own-Food * OSFC * We have some sponsors, but are still getting more * Ron needs photos from people “looking younger than they look today” for his anniversary talk * FSP 1.0 migration * Intel doesn’t seem to want to invest any resources in an update * Who is the owner for these at Intel? Is there a contact at this point? * Dhendricks might be able to work to get these updated to FSP 2.0 * AI: Patrick will look into the reasons for the migration (mailing list etc) and potentially write up a doc * Issue tracker * Over 200 users have applied but haven’t been authorized (never logged in). * Set up automatic notifications on IRC & current mailing list (& Set up new Mailing list if the bugs become too noisy) * AI: Patrick will look for plugins to get this set up.
Martin Roth wrote:
- Can we adopt on principle removing all cpp guards on protos?
Why would this be a good idea?
What does "cpp guards" actually refer to?
- Add cleanup task - remove guards specifically around prototypes?
- Having the prototypes outside of guards turns a compile time
error into a linker error.
Those sound like drawbacks?
- We should be more strict about how we define our blocks’ APIs.
Ok, but.. I just don't understand this proposal? Can someone explain?
Thanks
//Peter
- We should be more strict about how we define our blocks’ APIs.
Ok, but.. I just don't understand this proposal? Can someone explain?
I second this... this sounds like another code style discussion/change. Can we please keep all code style discussions on the mailing list? Or if there really needs to be a VC meeting for such a discussion, can it be pre-announced so everyone interested can participate?
Guys, it is a bit tricky to prevent discussions in a call when someone brings up a topic, and I'm not sure that blocking that is useful. The meetings are open and particularly people commenting here have been invited to the calls. Please make use of that opportunity and join, if you think that you have a strong opinion.
In this case, I made the suggestion to look at what is located in each heater file and cone up with clear interfaces, rather than jumping into the next "let's make coreboot source more similar to go by removing headset file guards" discussion.
On Thu, 23 May 2019, 16:43 Julius Werner, jwerner@chromium.org wrote:
- We should be more strict about how we define our blocks’ APIs.
Ok, but.. I just don't understand this proposal? Can someone explain?
I second this... this sounds like another code style discussion/change. Can we please keep all code style discussions on the mailing list? Or if there really needs to be a VC meeting for such a discussion, can it be pre-announced so everyone interested can participate?
- Can we adopt on principle removing all cpp guards on protos?
Why would this be a good idea? What does "cpp guards" actually refer to?
Upon re-reading this I *think* what they mean is stuff like
#if CONFIG(SOME_OPTION) void function_prototype(void); #endif
and not what I'd usually call "header guards":
#ifndef THIS_FILE_H #define THIS_FILE_H
...file contents
#endif /* THIS_FILE_H */
Cleaning up the former sounds reasonable to me, we already tend to avoid that for new code because it's just less clutter without really causing a problem (declaring extra prototypes don't hurt anyone), and it avoids problems with code that is unreachable but still compiled when CONFIG_SOME_OPTION is disabled.
Guys, it is a bit tricky to prevent discussions in a call when someone brings up a topic, and I'm not sure that blocking that is useful. The meetings are open and particularly people commenting here have been invited to the calls. Please make use of that opportunity and join, if you think that you have a strong opinion.
I think I got a bit spooked because the minutes were hard to understand and the "no decision made for now" sounds like another big change to how we are writing code at the moment might be coming down there in the future. If it's just a cleanup to conform to what has mostly been recent practice anyway it's not that big of a deal.
In general I think it's fine if you discuss things on the call as they come up, but if you notice that it's something that would interest the community at large (e.g. proposed style changes) it would be nice if you could summarize any discussion/opinions you had in an email afterwards and then continue further discussion on the mailing list. I guess that's somewhat what these minutes are, they were just a little unclear in this case (and it would probably better to have a separate topic for things of wider interest).
On Thu, May 23, 2019 at 6:13 PM Julius Werner jwerner@chromium.org wrote:
- Can we adopt on principle removing all cpp guards on protos?
Why would this be a good idea? What does "cpp guards" actually refer to?
Upon re-reading this I *think* what they mean is stuff like
#if CONFIG(SOME_OPTION) void function_prototype(void); #endif
yes. That's what the question meant: "should we remove cpp guards on protos", as it said. I guess "cpp guards" is just a term of art I grew up with, so did not realize it might confuse. OTOH it gets 2.5M hits.
I asked this question in the meeting because it came up in some reviews, and just for one example, https://review.coreboot.org/c/coreboot/+/32764/3/src/arch/x86/include/arch/a...
and in some of those reviews a number of comments were made that some of the guards on protos could be removed, even in cases where the functions in question were not used or defined. A function prototype essentially being a type declaration, this makes a sort of sense.
I also noticed this from https://review.coreboot.org/c/coreboot/+/30466/29/src/mainboard/sifive/hifiv... +++ b/src/mainboard/sifive/hifive-unleashed/flash.h @@ -0,0 +1,21 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2018 HardenedLinux + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __HIFIVE_UNLEASHED_FLASH_H__ +#define __HIFIVE_UNLEASHED_FLASH_H__ + +void flash_init(void); + +#endif /* __HIFIVE_UNLEASHED_FLASH_H__ */
This one file contains one prototype, i.e. one line, with three lines of cpp stuff to guard it. Is this sensible? I have no idea. But were we to adopt a policy of not guarding prototype declarations, we could, for a cpu or architecture, put all the protos in one file. That's what the Plan 9 authors (kernel written in C, by the inventors of Unix and C, for reference) elected to do. It was incredibly convenient -- all the protos you need were in one place. As weird as it sounds, it's very, very nice. I'm not recommending that for coreboot, just trying to point out what other projects have done.
But the overall observation was that we have guards around protos in some places, and in other places people have argued they can be removed, even when the function in question is not defined or used, and the question I got to wondering was: should we just remove all those guards, like Plan 9, or what?
There are situations where what would have been a compile time error is now a link time error. People might find this confusing.
The discussion evolved to a related question, around #pragma once. A few years back, on the Akaros project (kernel written in C, FWIW), a Linux kernel luminary convinced us to get rid of file guards and go to #pragma once. I am not sure it was worth the trouble but we did it. It *can* speed up compile time; cpp doesn't need to process a whole file and then conclude it did not have to process it; it can realize it can skip the open. A significant downside is that it's not in any standard -- just all the compilers out there, it seems, save romcc.
I did a simple test: apply #pragma once to coreboot. A coreboot build for watson opens 80K .h files today. #pragma once makes barely any difference; this says we are doing a good job in how we use our .h files.
From that point of view #pragma once hardly seems worth it. Either way, the build takes 35 seconds. For compilation speed, I see no advantage. And, again, #pragma once is not in any standard.
And that's it. I got kind of curious about usage of cpp guards, the meeting was on the schedule, I asked the question, and we discussed it. I value the opinions of the people on the call.
I'm sorry it elicited such a strong reaction.
As for the call: it's open. Anyone can call in. I'd be happy if more people did.
ron
Thanks for the detailed explanation Ron. FWIW I agree that removing guards like in acpi.h makes sense.
I did a simple test: apply #pragma once to coreboot. A coreboot build for watson opens 80K .h files today. #pragma once makes barely any difference; this says we are doing a good job in how we use our .h files.
AFAIK GCC nowadays has special support to detect the usual kind of header guard that spans the whole file because it is such a common pattern, and essentially treats it like #pragma once. That may be why you saw little difference.
On Thu, May 23, 2019 at 7:13 PM Julius Werner jwerner@chromium.org wrote:
... In general I think it's fine if you discuss things on the call as they come up, but if you notice that it's something that would interest the community at large (e.g. proposed style changes) it would be nice if you could summarize any discussion/opinions you had in an email afterwards and then continue further discussion on the mailing list. I guess that's somewhat what these minutes are, they were just a little unclear in this case (and it would probably better to have a separate topic for things of wider interest).
Hi Julius, Thanks for your feedback. We know that the minutes aren't the best, and have discussed finding someone other than Patrick and I to take the minutes, but so far we haven't found anyone to do that. If you or anyone else would like to volunteer to help take better minutes of the meeting and send them out afterwards, I think everyone would welcome that.
As I mentioned at the head of the meeting minutes, the call-in information is in the public coreboot calendar. Everyone's invited to hear what we're discussing if they're interested. https://coreboot.org/calendar.html
We've taken big steps to make things public, and we're sending out the meeting minutes to the mailing list. All of the minutes are also in a public location: https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...
Honestly though, I don't think that anything we can note in the meeting is sufficient. There will always be questions, and i think just bringing them up on the mailing list afterwards and asking questions is totally appropriate.
Martin
-
Julius Werner -
Martin Roth -
Peter Stuge -
ron minnich -
Stefan Reinauer