Hi Bertrand,
On 04/05/2022 10:49, Bertrand Marquis wrote:
On 4 May 2022, at 09:20, Julien Grall <[email protected]> wrote:
On 04/05/2022 08:39, Bertrand Marquis wrote:
Hi Julien,
Hi,
On 3 May 2022, at 19:08, Julien Grall <[email protected]> wrote:
Hi Bertrand,
On 03/05/2022 10:38, Bertrand Marquis wrote:
Sync arm64 sysreg bit shift definitions with status of Linux kernel as
of 5.18-rc3 version (linux commit b2d229d4ddb1).
Sync ID registers sanitization with the status of Linux 5.18-rc3 and add
sanitization of ISAR2 registers.
Please outline which specific commits you are actually backported. This would
help to know what changed, why and also keep track of the autorships.
When possible, the changes should be separated to match each Linux commit we
backport.
As those are exactly identical to the linux tree, one can easily use git blame
on the linux source tree to find those information if it is needed
Well... that's possible at the cost of everyone going through Linux to
understand why the changes were made. This is not very scalable.
I checked a bit and this is not something that was required before (for example
when the cpufeature was introduced).
If we import the full file, then we will generally don't log all the commits.
However, for smaller changes, we will always mention the commit backported.
There are several examples on the ML:
- 0435784cc75d ("xen/arm: smmuv1: Intelligent SMR allocation")
- 9c432b876bf5 ("x86/mwait-idle: add SPR support")
We also recently introduced a tag "Origin:" to keep track of which commit was
backported. If you want to understand the rationale, you can read this long thread:
https://lore.kernel.org/xen-devel/[email protected]/
Do I understand right that it is ok for you if I push one patch mentioning all
the commits done in Linux corresponding to the changes (instead of one patch
per commit) ?
For this case yes.
Cheers,
--
Julien Grall
