public inbox for dwarves@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ihor Solodrai" <ihor.solodrai@linux.dev>
To: "Alan Maguire" <alan.maguire@oracle.com>, acme@kernel.org
Cc: yonghong.song@linux.dev, dwarves@vger.kernel.org, ast@kernel.org,
	andrii@kernel.org, bpf@vger.kernel.org, daniel@iogearbox.net,
	song@kernel.org, eddyz87@gmail.com, olsajiri@gmail.com
Subject: Re: [PATCH v2 dwarves 1/2] dwarves: Add github actions to build, test
Date: Wed, 09 Apr 2025 15:52:03 +0000	[thread overview]
Message-ID: <8f5711430e4f9bb02fd06d3a5b00d46d8643fea1@linux.dev> (raw)
In-Reply-To: <290e2542-fc51-402f-b84b-00e1f2ca2bfa@oracle.com>

On 4/9/25 1:59 AM, Alan Maguire wrote:
> 
>>> [...]
>>> +
>>> +cat tools/testing/selftests/bpf/config \
>>> +    tools/testing/selftests/bpf/config.${INPUTS_ARCH} > .config
>>> +# this file might or might not exist depending on kernel version
>>> +if [[ -f tools/testing/selftests/bpf/config.vm ]]; then
>>> +	cat tools/testing/selftests/bpf/config.vm >> .config
>>> +fi
>>> +make olddefconfig && make prepare
>>> +grep PAHOLE .config
>>> +grep _BTF .config
>>
>> This looks like debugging code, but instead of removing it I think it
>> is useful to dump entire config to the output (hence job log) in case
>> something goes wrong. How about `cat .config` before make
>> olddefconfig?
>>
>
> Sounds good, but would doing it after "make olddefconfig" be more
> informative maybe since some additional values may be set?

I think as long as you know what is being printed it's ok. The config
after olddefconfig is the full expanded config, which is quite big.

> [...]
>
>>> diff --git a/.github/workflows/vmtest.yml b/.github/workflows/vmtest.yml
>>> new file mode 100644
>>> index 0000000..0f66eed
>>> --- /dev/null
>>> +++ b/.github/workflows/vmtest.yml
>>> @@ -0,0 +1,62 @@
>>> +name: 'Build kernel run selftests via vmtest'
>>> +
>>> +on:
>>> +  workflow_call:
>>> +    inputs:
>>> +      runs_on:
>>> +        required: true
>>> +        default: 'ubuntu-24.04'
>>> +        type: string
>>> +      arch:
>>> +        description: 'what arch to test'
>>> +        required: true
>>> +        default: 'x86_64'
>>> +        type: string
>>> +      kernel:
>>> +        description: 'kernel version or LATEST'
>>> +        required: true
>>> +        default: 'LATEST'
>>> +        type: string
>>> +      pahole:
>>> +        description: 'pahole rev or branch'
>>> +        required: false
>>> +        default: 'master'
>>> +        type: string
>>> +      llvm-version:
>>> +        description: 'llvm version'
>>> +        required: false
>>> +        default: '18'
>>> +        type: string
>>> +jobs:
>>> +  vmtest:
>>> +    name: pahole@${{ inputs.arch }}
>>> +    runs-on: ${{ inputs.runs_on }}
>>> +    steps:
>>> +
>>> +      - uses: actions/checkout@v4
>>> +
>>> +      - name: Setup environment
>>> +        uses: libbpf/ci/setup-build-env@v3
>>> +        with:
>>> +          pahole: ${{ inputs.pahole }}
>>> +          arch: ${{ inputs.arch }}
>>> +          llvm-version: ${{ inputs.llvm-version }}
>>
>> I think I mentioned it before, but libbpf/ci/setup-build-env checks
>> out and installs pahole too, which is unnecessary here. Have you tried
>> removing this step from the job?
>>
>> You should be able to reuse a piece of SETUP logic from
>> build-debian.sh to install pahole's dependencies. Although you kernel
>> build deps are needed too.
>>
>
> Yeah it's the latter that are needed I think.
>
>> I could make a change in libbpf/ci/setup-build-env to accept a special
>> `pahole` input value or check for env variable to NOT build pahole.
>> What do you think?
>
> That would be great! Something like "pahole: none"?

Yes, something like that. It's a small change. I'll let you know when
it's done.

>
> I'll probably try and land this more or less as-is as we're hoping to
> get 1.30 out the door this week, but definitely will follow up with
> builds with shared library libbpf etc. Thanks for taking a look!
>
> Alan

  reply	other threads:[~2025-04-09 15:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-01  9:24 [PATCH v2 dwarves 0/2] dwarves: Introduce github actions for CI Alan Maguire
2025-04-01  9:24 ` [PATCH v2 dwarves 1/2] dwarves: Add github actions to build, test Alan Maguire
2025-04-08 19:09   ` Ihor Solodrai
2025-04-09  8:59     ` Alan Maguire
2025-04-09 15:52       ` Ihor Solodrai [this message]
2025-04-17 23:23         ` Ihor Solodrai
2025-04-01  9:24 ` [PATCH v2 dwarves 2/2] dwarves: Fix clang warning about unused variable Alan Maguire
2025-04-10 18:04 ` [PATCH v2 dwarves 0/2] dwarves: Introduce github actions for CI Alan Maguire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f5711430e4f9bb02fd06d3a5b00d46d8643fea1@linux.dev \
    --to=ihor.solodrai@linux.dev \
    --cc=acme@kernel.org \
    --cc=alan.maguire@oracle.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dwarves@vger.kernel.org \
    --cc=eddyz87@gmail.com \
    --cc=olsajiri@gmail.com \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox