Branch for kernelci
A message that is not in the archive (sent off-list or not yet received): [email protected]
Please add testing for Will Deacon's ARM64 staging tree to kernelci:
[web] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-kernelci
[git] git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
It would make sense to have dashboard available as "arm64" or some other unique tree name (eg "https://kernelci.org/job/arm64").
The owners of this tree are the ARM64 maintainers: [email protected] and [email protected] (CC'd)
-Todd
Quoted 10 lines · Todd Kjos via Groups.Io
Please add testing for Will Deacon's ARM64 staging tree to kernelci:
[web] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-kernelci
[git]git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.gitfor-kernelciIt would make sense to have dashboard available as "arm64" or some other unique tree name (eg "https://kernelci.org/job/arm64").
The owners of this tree are the ARM64 maintainers: [email protected] and [email protected] (CC'd)
Are you sure they are interested in this? When asked previously they indicated that they didn't see any extra value in covering their tree specifically separately to -next.
Quoted 9 lines · Mark Brown
Quoted 7 lines · Todd Kjos via Groups.Io
Please add testing for Will Deacon's ARM64 staging tree to kernelci:
[web] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-kernelci
[git]git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.gitfor-kernelciIt would make sense to have dashboard available as "arm64" or some other unique tree name (eg "https://kernelci.org/job/arm64").
Quoted 6 lines
Quoted 2 lines
The owners of this tree are the ARM64 maintainers: [email protected] and [email protected] (CC'd)
Are you sure they are interested in this? When asked previously they indicated that they didn't see any extra value in covering their tree specifically separately to -next.
Will can comment on the reasoning but I guess it came as a request from him since he also created the arm64/for-kernelci branch. This might as well be the same as for-next/core but tested in isolation rather than with the whole linux-next tree.
Signature · 1 line
Catalin
Quoted 10 lines · Catalin Marinas
Quoted 3 lines · Mark Brown
Are you sure they are interested in this? When asked previously they indicated that they didn't see any extra value in covering their tree specifically separately to -next.
Will can comment on the reasoning but I guess it came as a request from him since he also created the arm64/for-kernelci branch. This might as well be the same as for-next/core but tested in isolation rather than with the whole linux-next tree.
Yeah, that was what you'd both rejected doing before which was why I was surprised (plus the fact that this was coming via Todd rather than one of you).
Quoted 7 lines · Mark Brown
Quoted 5 lines · Catalin Marinas
Quoted 3 lines · Mark Brown
Are you sure they are interested in this? When asked previously they indicated that they didn't see any extra value in covering their tree specifically separately to -next.
Quoted 8 lines
Quoted 4 lines
Will can comment on the reasoning but I guess it came as a request from him since he also created the arm64/for-kernelci branch. This might as well be the same as for-next/core but tested in isolation rather than with the whole linux-next tree.
Yeah, that was what you'd both rejected doing before which was why I was surprised (plus the fact that this was coming via Todd rather than one of you).
I asked Todd about this yesterday because we're dealing with an ABI regression in 5.4 which wasn't picked up until -rc3, so figured that this was probably worth doing after all. Perhaps it wouldn't have helped for this specific case, but it turns out that one person's LTP isn't quite the same as another person's LTP!
So yes, I'm interested in having our for-kernelci branch picked up despite not seeing the benefit in the past.
Thanks,
Will
----- Original Message -----
Quoted 23 lines
From: "Will Deacon" <[email protected]>
To: "Mark Brown" <[email protected]>
Cc: "Catalin Marinas" <[email protected]>, [email protected], [email protected]
Sent: Wednesday, October 16, 2019 6:46:22 PM
Subject: Re: Branch for kernelciQuoted 7 lines · Mark Brown
Quoted 5 lines · Catalin Marinas
Quoted 3 lines · Mark Brown
Are you sure they are interested in this? When asked previously they indicated that they didn't see any extra value in covering their tree specifically separately to -next.
Quoted 8 lines
Quoted 4 lines
Will can comment on the reasoning but I guess it came as a request from him since he also created the arm64/for-kernelci branch. This might as well be the same as for-next/core but tested in isolation rather than with the whole linux-next tree.
Yeah, that was what you'd both rejected doing before which was why I was surprised (plus the fact that this was coming via Todd rather than one of you).
Quoted 6 lines
I asked Todd about this yesterday because we're dealing with an ABI regression in 5.4 which wasn't picked up until -rc3, so figured that this was probably worth doing after all. Perhaps it wouldn't have helped for this specific case, but it turns out that one person's LTP isn't quite the same as another person's LTP!
Hi,
if you're mentioning the regression from this thread [0] you'd need to have the tree added to CKI, not KernelCI. Not sure if we're ready to handle mainline/next speed of development yet but we can discuss the specifics and decide based on that. The issue/PR with details be submitted here [1].
We only enabled Sasha's stable-next branch two weeks ago and openposix tests last week so we're definitely happy they are catching issues right away!
We are actively collaborating with KernelCI but right now the testing systems, machine pools and testsuites are pretty much independent.
Quoted 3 lines
So yes, I'm interested in having our for-kernelci branch picked up despite not seeing the benefit in the past.
Glad to see the interest for CI!
Let me know if you have any questions,
Veronika
[0] https://lists.linaro.org/pipermail/linux-stable-mirror/2019-October/137969.html
[1] https://gitlab.com/cki-project/pipeline-data
Quoted 7 lines
Thanks,
Will
Quoted 31 lines · Veronika Kabatova
----- Original Message -----
Quoted 23 lines
From: "Will Deacon" <[email protected]>
To: "Mark Brown" <[email protected]>
Cc: "Catalin Marinas" <[email protected]>, [email protected], [email protected]
Sent: Wednesday, October 16, 2019 6:46:22 PM
Subject: Re: Branch for kernelciQuoted 7 lines · Mark Brown
Quoted 5 lines · Catalin Marinas
Quoted 3 lines · Mark Brown
Are you sure they are interested in this? When asked previously they indicated that they didn't see any extra value in covering their tree specifically separately to -next.
Quoted 8 lines
Quoted 4 lines
Will can comment on the reasoning but I guess it came as a request from him since he also created the arm64/for-kernelci branch. This might as well be the same as for-next/core but tested in isolation rather than with the whole linux-next tree.
Yeah, that was what you'd both rejected doing before which was why I was surprised (plus the fact that this was coming via Todd rather than one of you).
Quoted 6 lines
I asked Todd about this yesterday because we're dealing with an ABI regression in 5.4 which wasn't picked up until -rc3, so figured that this was probably worth doing after all. Perhaps it wouldn't have helped for this specific case, but it turns out that one person's LTP isn't quite the same as another person's LTP!
Quoted 4 lines
if you're mentioning the regression from this thread [0] you'd need to have the tree added to CKI, not KernelCI. Not sure if we're ready to handle mainline/next speed of development yet but we can discuss the specifics and decide based on that. The issue/PR with details be submitted here [1].
Hopefully the two aren't mutually exclusive, so if you're able to add the branch to CKI as well then that would be great.
Will
----- Original Message -----
Quoted 47 lines
From: "Will Deacon" <[email protected]>
To: "Veronika Kabatova" <[email protected]>
Cc: [email protected], "Mark Brown" <[email protected]>, "Catalin Marinas" <[email protected]>, [email protected]
Sent: Thursday, October 17, 2019 1:50:55 AM
Subject: Re: Branch for kernelciQuoted 39 lines · Veronika Kabatova
----- Original Message -----
Quoted 37 lines
From: "Will Deacon" <[email protected]>
To: "Mark Brown" <[email protected]>
Cc: "Catalin Marinas" <[email protected]>, [email protected], [email protected]
Sent: Wednesday, October 16, 2019 6:46:22 PM
Subject: Re: Branch for kernelciQuoted 16 lines · Mark Brown
Quoted 8 lines · Catalin Marinas
Quoted 5 lines · Mark Brown
Are you sure they are interested in this? When asked previously they
indicated that they didn't see any extra value in covering their tree
specifically separately to -next.Quoted 6 lines
Will can comment on the reasoning but I guess it came as a request from
him since he also created the arm64/for-kernelci branch. This might as
well be the same as for-next/core but tested in isolation rather than with the whole linux-next tree.Quoted 4 lines
Yeah, that was what you'd both rejected doing before which was why I was
surprised (plus the fact that this was coming via Todd rather than one of you).I asked Todd about this yesterday because we're dealing with an ABI regression in 5.4 which wasn't picked up until -rc3, so figured that this was probably worth doing after all. Perhaps it wouldn't have helped for this
specific case, but it turns out that one person's LTP isn't quite the same
as another person's LTP!
Quoted 8 lines
Quoted 4 lines
if you're mentioning the regression from this thread [0] you'd need to have the tree added to CKI, not KernelCI. Not sure if we're ready to handle mainline/next speed of development yet but we can discuss the specifics and decide based on that. The issue/PR with details be submitted here [1].
Hopefully the two aren't mutually exclusive, so if you're able to add the branch to CKI as well then that would be great.
Of course not. Is testing on aarch64 sufficient or do you need other architectures too?
I submitted [0] the initial config, please check if the repo and email information are correct or if we should add e.g. ARM list (didn't see it in the initial email but checking just in case).
[0] https://gitlab.com/cki-project/pipeline-data/merge_requests/19/diffs
Veronika
Quoted 5 lines
Will
Hi Veronika,
Quoted 15 lines · Veronika Kabatova
Quoted 15 lines · Veronika Kabatova
Quoted 13 lines
Quoted 8 lines
I asked Todd about this yesterday because we're dealing with an ABI regression in 5.4 which wasn't picked up until -rc3, so figured that this was probably worth doing after all. Perhaps it wouldn't have helped for this
specific case, but it turns out that one person's LTP isn't quite the same
as another person's LTP!if you're mentioning the regression from this thread [0] you'd need to have the tree added to CKI, not KernelCI. Not sure if we're ready to handle mainline/next speed of development yet but we can discuss the specifics and decide based on that. The issue/PR with details be submitted here [1].
Quoted 6 lines
Quoted 3 lines
Hopefully the two aren't mutually exclusive, so if you're able to add the branch to CKI as well then that would be great.
Of course not. Is testing on aarch64 sufficient or do you need other architectures too?
Oh, good question! I suppose the two targets we care about the most are arm64 kernel with both arm64 and arm32 userspace.
Quoted 3 lines
I submitted [0] the initial config, please check if the repo and email information are correct or if we should add e.g. ARM list (didn't see it in the initial email but checking just in case).
Brilliant, thanks very much. I hadn't considered adding the list, but I guess it doesn't hurt so please feel free to add [email protected] as well.
Curious: why 'olddefconfig' instead of 'defconfig'? Are there some options required by CKI that aren't present in defconfig?
Will
Quoted 2 lines · Will Deacon
Curious: why 'olddefconfig' instead of 'defconfig'? Are there some options required by CKI that aren't present in defconfig?
In general anything that's doing runtime tests will need some extra config options to get the functionality they're trying to test enabled, for example for kselftests there's fragments in tree as tools/testing/selftests/*/config (a lot though not all of those tend to end up in defconfigs but other testsuites end up adding more). This was why Anders was looking at making allmodconfig bootable, it'd reduce the need for this.
----- Original Message -----
Quoted 33 lines
From: "Will Deacon" <[email protected]>
To: "Veronika Kabatova" <[email protected]>
Cc: [email protected], "Mark Brown" <[email protected]>, "Catalin Marinas" <[email protected]>, [email protected]
Sent: Thursday, October 17, 2019 6:02:43 PM
Subject: Re: Branch for kernelciHi Veronika,
Quoted 23 lines · Veronika Kabatova
Quoted 22 lines · Veronika Kabatova
Quoted 11 lines
Quoted 10 lines
I asked Todd about this yesterday because we're dealing with an ABI regression in 5.4 which wasn't picked up until -rc3, so figured that this
was probably worth doing after all. Perhaps it wouldn't have helped for
this
specific case, but it turns out that one person's LTP isn't quite the same
as another person's LTP!Quoted 6 lines
if you're mentioning the regression from this thread [0] you'd need to have
the tree added to CKI, not KernelCI. Not sure if we're ready to handle mainline/next speed of development yet but we can discuss the specifics and
decide based on that. The issue/PR with details be submitted here [1].Hopefully the two aren't mutually exclusive, so if you're able to add the branch to CKI as well then that would be great.
Quoted 6 lines
Quoted 2 lines
Of course not. Is testing on aarch64 sufficient or do you need other architectures too?
Oh, good question! I suppose the two targets we care about the most are arm64 kernel with both arm64 and arm32 userspace.
I think we only have arm64. Thanks for answer, I'll adjust the tree config to only use aarch64 for now.
Quoted 8 lines
Quoted 3 lines
I submitted [0] the initial config, please check if the repo and email information are correct or if we should add e.g. ARM list (didn't see it in the initial email but checking just in case).
Brilliant, thanks very much. I hadn't considered adding the list, but I guess it doesn't hurt so please feel free to add [email protected] as well.
Will add!
Quoted 3 lines
Curious: why 'olddefconfig' instead of 'defconfig'? Are there some options required by CKI that aren't present in defconfig?
We're using Fedora config files with this option. I honestly don't know if there are any tests depending on it, but we are trying to build kernels close to the Fedora ones.
I'll get all the CKI configs in place and the first test run should start soon after they are merged.
Veronika
Quoted 2 lines
Will
Quoted 24 lines · Will Deacon
Quoted 7 lines · Mark Brown
Quoted 5 lines · Catalin Marinas
Quoted 3 lines · Mark Brown
Are you sure they are interested in this? When asked previously they indicated that they didn't see any extra value in covering their tree specifically separately to -next.
Quoted 8 lines
Quoted 4 lines
Will can comment on the reasoning but I guess it came as a request from him since he also created the arm64/for-kernelci branch. This might as well be the same as for-next/core but tested in isolation rather than with the whole linux-next tree.
Yeah, that was what you'd both rejected doing before which was why I was surprised (plus the fact that this was coming via Todd rather than one of you).
I asked Todd about this yesterday because we're dealing with an ABI regression in 5.4 which wasn't picked up until -rc3, so figured that this was probably worth doing after all. Perhaps it wouldn't have helped for this
specific case, but it turns out that one person's LTP isn't quite the same as another person's LTP!
Quoted 3 lines
So yes, I'm interested in having our for-kernelci branch picked up despite not seeing the benefit in the past.
Sure, sorry for the delay in getting this sorted out. There are a few pieces of information needed in order to add a branch to kernelci.org, and to avoid repeating the same questions every time I've now made a Github issue template just for that:
https://github.com/kernelci/kernelci-core/issues/new/choose
Would you be so kind as to filing one of those? You'll be the first one actually using this template so I hope it'll be self-explanatory but please let us know if you have any questions or comments.
Thanks,
Guillaume
Quoted 3 lines
Hi Guillaume,
Thanks for the reply.
Quoted 10 lines · Guillaume Tucker
On Wed, Oct 16, 2019 at 5:55 PM Will Deacon <[1][email protected]> wrote:
So yes, I'm interested in having our for-kernelci branch picked up despite
not seeing the benefit in the past.Sure, sorry for the delay in getting this sorted out. There are a few pieces of information needed in order to add a branch to [2]kernelci.org, and to avoid repeating the same questions every time I've now made a Github issue template just for that:
Quoted 6 lines
[3]https://github.com/kernelci/kernelci-core/issues/new/choose
Would you be so kind as to filing one of those? You'll be the first one actually using this template so I hope it'll be self-explanatory but please let us know if you have any questions or comments.
Hmm, so I don't actually have a github account anymore and it feels a bit OTT to create one just to fill in a form... Is the form accessible some other way?
Will
Quoted 18 lines · Will Deacon
Hi Guillaume,
Thanks for the reply.
Quoted 1 line · Guillaume Tucker
On Wed, Oct 16, 2019 at 5:55 PM Will Deacon <[1][email protected]>
Quoted 11 lines · wrote:
So yes, I'm interested in having our for-kernelci branch picked up despite
not seeing the benefit in the past.Sure, sorry for the delay in getting this sorted out. There are a few pieces of information needed in order to add a branch to [2]kernelci.org, and to avoid repeating the same questions every time I've now made a Github issue template just for that:
[3]https://github.com/kernelci/kernelci-core/issues/new/choose
Quoted 8 lines
Quoted 4 lines
Would you be so kind as to filing one of those? You'll be the first one actually using this template so I hope it'll be self-explanatory but please let us know if you have any questions or comments.
Hmm, so I don't actually have a github account anymore and it feels a bit OTT to create one just to fill in a form... Is the form accessible some other way?
Alright then, I'll ask you a couple of things here instead:
How much build coverage do you need for your branch? Is it just for arm64, or do you need other architectures to be built as well? Do you need only the main defconfig or do you want all the variants such as allmodconfig, defconfig with big-endian...
How often do you expect your branch to be updated? Every branch is monitored hourly on kernelci.org, so if it's updated less often then it's easier to cope with a larger build coverage.
Which recipients should receive the email reports? The standard reports are for builds and basic tests (boot and checks for kernel errors). I guess that should be Catalin, you and linux-arm-kernel as for CKI?
Guillaume
Hi Guillaume,
Quoted 13 lines · Guillaume Tucker
On Wed, Oct 23, 2019 at 5:42 PM Will Deacon <[1][email protected]> wrote:
On Tue, Oct 22, 2019 at 08:53:03PM +0100, Guillaume Tucker wrote:
> [3][4]https://github.com/kernelci/kernelci-core/issues/new/choose >
> Would you be so kind as to filing one of those? You'll be the > first one actually using this template so I hope it'll be > self-explanatory but please let us know if you have any questions > or comments.Hmm, so I don't actually have a github account anymore and it feels a bit OTT to create one just to fill in a form... Is the form accessible some other way?
Quoted 5 lines
Alright then, I'll ask you a couple of things here instead:
How much build coverage do you need for your branch? Is it just for arm64, or do you need other architectures to be built as well? Do you need only the main defconfig or do you want all the variants such as allmodconfig, defconfig with big-endian...
arm64 only, with build coverage for allnoconfig, defconfig and allmodconfig. The boot/runtime tests only need to worry about defconfig.
Quoted 3 lines
How often do you expect your branch to be updated? Every branch is monitored hourly on [5]kernelci.org, so if it's updated less often then it's easier to cope with a larger build coverage.
Hard to tell, but at most maybe once a day?
Quoted 4 lines
Which recipients should receive the email reports? The standard reports are for builds and basic tests (boot and checks for kernel errors). I guess that should be Catalin, you and linux-arm-kernel as for CKI?
Yes, please.
Thanks,
Will
Hi Will,
Quoted 26 lines · Will Deacon
Hi Guillaume,
Quoted 1 line · Guillaume Tucker
On Wed, Oct 23, 2019 at 5:42 PM Will Deacon <[1][email protected]>
Quoted 2 lines · wrote:
On Tue, Oct 22, 2019 at 08:53:03PM +0100, Guillaume Tucker wrote: > [3][4]https://github.com/kernelci/kernelci-core/issues/new/choose
Quoted 4 lines
>
> Would you be so kind as to filing one of those? You'll be the
> first one actually using this template so I hope it'll be
> self-explanatory but please let us know if you have anyquestions
Quoted 3 lines
> or comments.
Hmm, so I don't actually have a github account anymore and it feels
a
Quoted 8 lines
bit OTT to create one just to fill in a form... Is the form accessible some other way?
Alright then, I'll ask you a couple of things here instead:
How much build coverage do you need for your branch? Is it just for arm64, or do you need other architectures to be built as well? Do you need only the main defconfig or do you want all the variants such as allmodconfig, defconfig with big-endian...
Quoted 4 lines
arm64 only, with build coverage for allnoconfig, defconfig and allmodconfig.
The boot/runtime tests only need to worry about defconfig.
Sure.
Meanwhile, we should hopefully soon have a bootable allmodconfig on arm64 using KBUILD_ALLCONFIG to pick default choices from the regular defconfig. You might be interested in that when it happens, the KernelCI parts are all in place and Anders is now on the case to make it actually work with tweaks in the defconfig.
Quoted 6 lines
Quoted 3 lines
How often do you expect your branch to be updated? Every branch is monitored hourly on [5]kernelci.org, so if it's updated less often then it's easier to cope with a larger build coverage.
Hard to tell, but at most maybe once a day?
That's fine, it's mostly an issue for branches that get built with the full range of combinations and new each revision produces over 200 kernels binaries...
Quoted 7 lines
Quoted 4 lines
Which recipients should receive the email reports? The standard reports are for builds and basic tests (boot and checks for kernel errors). I guess that should be Catalin, you and linux-arm-kernel as for CKI?
Yes, please.
OK here's the pull request for the record:
https://github.com/kernelci/kernelci-core/pull/224
If all goes well this should be enabled later this week during the next kernelci.org update.
Thanks,
Guillaume