[coreboot] [Coreboot] [GSoC 2022] Interested in Contributing

[Ahamed Husni]

Hi all,

I am an undergraduate student interested to learn and contribute to
Coreboot.
I have no prior experience in Coreboot related development. Once I tried to
add heap overflow detection support in AddressSanitizer [Patch
] as an extension to the
GSoC 2020 ASan project.

I find the following projects interesting to me.

   1. U-Boot EFI Payload integration (New)
   2. Port payloads to ARM, AArch64 or RISC-V
   



If I could get the following information regarding the projects, it'll be
really helpful.

   - Prerequisites for each project
   - Size of the projects (medium:~175 hours, large:~350 hours - from GSoC
   blog)
   - Required hardwares


I have some experience with C programming.
Hardwares with me now:

   - Intel Galileo Gen 2
   - Beaglebone Black with JLink
   - Raspberry Pi 3B+,3A

If there are other projects which might interest me, please let me know.

Best Regards,
Husni.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS refactoring)

[Nico Huber]

On 12.01.22 18:11, Jeff Daly wrote:
> If I don't have to do anything, then I won't.   I wasn't sure whether commits 
> that are marked with conflicts tend to get less attention than ones that 
> don't.   I've been rebasing for amending earlier commits so I guess at least 
> I'm doing that correctly.   What I'm confused with is as you said, if I'm 
> removing lines it will try to remove them, and fail if something changed 
> between the 2 bases.  I'm the only one making any changes, so that shouldn't 
> be an issue.I understand the file replacement explanation as well, but 
> again nothing changed in the file in the base I'm working on and by rebasing 
> against master before pushing, I'd see the merge conflict.  If my change got 
> in before someone elses, then they'd see the merge conflict when they went to 
> push.

The xHCI patch on Gerrit is currently based on one changing the PCI ID
macro in `xhci.c`. When you cherry-pick the xHCI commit alone (on master
where the macro name didn't change), the file contents are different.

Nico

>
>
> -Original Message-
> From: Nico Huber 
> Sent: Wednesday, January 12, 2022 12:04 PM
> To: Jeff Daly ; Paul Menzel ; 
> coreboot@coreboot.org
> Subject: Re: [coreboot] Re: Gerrit shows a Merge Conflict (was: Re: 
> Denverton-NS refactoring)
>
> Caution: This is an external email. Please take care when clicking links or 
> opening attachments.
>
>
> On 12.01.22 16:21, Jeff Daly wrote:
>> Ok that sort of makes sense, but for example in the case of the XHCI patch, 
>> the merge conflict appears to be that since soc/intel/denverton_ns/xhci.c 
>> was changed completely to reflect the usage of the common code and shouldn't 
>> cause an issue with being cherry-picked onto master...
>>
>> So, I just tried it and see that it comes up with the merge conflict.  I 
>> guess the merge operation is super-cautious and prefers the developer to do 
>> a manual merge vs always accepting the newer code?  Is there a setting that 
>> can be modified for that?
>
> I don't know any setting to change that. It's simple tools, AFAICT. If you 
> supply them a patch with something to remove they'll try to find the 
> respective line to remove and fail if that line changed between the two 
> bases. Git cannot see that the intention is to replace the entire file no 
> matter its current contents. To a human that might be obvious but also only 
> in the context of your whole patch train. IMO that's correct behavior. For 
> instance, if somebody else added something to that file in the meantime, 
> would the intention still be to replace the whole file? How to decide that 
> automatically?
>
>> Having to do a merge resolution for wholesale changes to code seems 
>> counter-productive.
>
> You don't have to do anything unless you want to re-organize your patch 
> train. For instance, change the order of commits you currently have on one 
> branch. But is that really what you want?
>
>>
>> Next question would be, what's the best mechanism to do this and not mess up 
>> my patch train again.  I want to keep all the relationships in gerrit so the 
>> progression can be visualized.  I have a clean master branch and the 
>> denverton_refactor branch locally where I'm keeping my changes.  I'd like to 
>> keep it in denverton_refactor locally.  is it required that I need to 
>> apply the merge resolution commit on the master branch or can I rewind my 
>> branch to the offending commit^ and do git pull --rebase at that point?
>
> I'm afraid I don't follow. What is it that you want to do that results in the 
> conflict in the first place?
>
> Generally our Gerrit setup doesn't allow merge commits. If you want to amend 
> a commit on your branch, you have to rebase.
>
> But a `git pull --rebase` would rebase on top of upstream (I assume).
> That's sometimes useful, but rather a potential cause of conflicts than a 
> resolution.
>
> Nico
>

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Gerrit shows a Merge Conflict (was: Re: Denverton-NS refactoring)

[Nico Huber]

On 12.01.22 16:21, Jeff Daly wrote:
> Ok that sort of makes sense, but for example in the case of the XHCI patch, 
> the merge conflict appears to be that since soc/intel/denverton_ns/xhci.c was 
> changed completely to reflect the usage of the common code and shouldn't 
> cause an issue with being cherry-picked onto master...
>
> So, I just tried it and see that it comes up with the merge conflict.  I 
> guess the merge operation is super-cautious and prefers the developer to do a 
> manual merge vs always accepting the newer code?  Is there a setting that can 
> be modified for that?

I don't know any setting to change that. It's simple tools, AFAICT. If
you supply them a patch with something to remove they'll try to find the
respective line to remove and fail if that line changed between the two
bases. Git cannot see that the intention is to replace the entire file
no matter its current contents. To a human that might be obvious but
also only in the context of your whole patch train. IMO that's correct
behavior. For instance, if somebody else added something to that file
in the meantime, would the intention still be to replace the whole
file? How to decide that automatically?

> Having to do a merge resolution for wholesale changes to code seems 
> counter-productive.

You don't have to do anything unless you want to re-organize your patch
train. For instance, change the order of commits you currently have on
one branch. But is that really what you want?

>
> Next question would be, what's the best mechanism to do this and not mess up 
> my patch train again.  I want to keep all the relationships in gerrit so the 
> progression can be visualized.  I have a clean master branch and the 
> denverton_refactor branch locally where I'm keeping my changes.  I'd like to 
> keep it in denverton_refactor locally.  is it required that I need to 
> apply the merge resolution commit on the master branch or can I rewind my 
> branch to the offending commit^ and do git pull --rebase at that point?

I'm afraid I don't follow. What is it that you want to do that results
in the conflict in the first place?

Generally our Gerrit setup doesn't allow merge commits. If you want to
amend a commit on your branch, you have to rebase.

But a `git pull --rebase` would rebase on top of upstream (I assume).
That's sometimes useful, but rather a potential cause of conflicts
than a resolution.

Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org