Conor Dooley
Posts
507Following
144Followers
178I like cycling, powerlifting, bad video games and metal.
Otherwise, I occupy my time with various bits in RISC-V land.
~useless, placeholder, website: https://www.conchuod.ie/
Conor Dooley
repeated
repeated
Palmer Dabbelt
palmer
Vector uABI thread on sw-dev: https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/9CI304vHtMo
1
3
4
Conor Dooley
conor
You think you're gonna sit down and get something done for once, and then CI failures left right and centre :)
0
0
2
@pdp7 @palmer If you don't like the template being there, you can always write a b4-cover-template file & point to it with `b4.prep-cover-template` in your git config (see https://b4.docs.kernel.org/en/latest/config.html#contributor-settings).
The default is:
```
${cover}
---
${shortlog}
${diffstat}
---
base-commit: ${base_commit}
change-id: ${change_id}
Best regards,
--
${signature}
```
The default is:
```
${cover}
---
${shortlog}
${diffstat}
---
base-commit: ${base_commit}
change-id: ${change_id}
Best regards,
--
${signature}
```
1
0
1
@matttbe @kernellogger checkpatch isn't an arbiter of truth to begin with, especially in arch code it reports a bunch of spurious stuff.
I was just a bit annoyed by it the other day when checkpatch complained, telling me that I should have a Closes: pointing to a competing patch for a problem.
I guess I had had it in my head that what was accepted was going to allow Reported-by: followed by Link: & complain only about "bare" Reported-by:.
> it is similar to the previous situation where there are cases where it doesn't even make sense to have a Link tag after a Reported-by.
Yah, that's probably fair.
I was just a bit annoyed by it the other day when checkpatch complained, telling me that I should have a Closes: pointing to a competing patch for a problem.
I guess I had had it in my head that what was accepted was going to allow Reported-by: followed by Link: & complain only about "bare" Reported-by:.
> it is similar to the previous situation where there are cases where it doesn't even make sense to have a Link tag after a Reported-by.
Yah, that's probably fair.
0
0
1
@kernellogger @matttbe I would like to make my CI stuff entirely ignore that tag, complaint, but I don't immediately see an ignore.
0
0
0
@kernellogger @matttbe yeah, partially due to patches that only fix part of a reported issue (I think I was the one who mentioned it on LKML) but also "Closes:" is a very definitive statement, when quite often a fix does not in fact entirely fix the problem.
1
0
0
Conor Dooley
conor
@kernellogger I see the "Reported-by: should be immediately followed by Closes: with a URL to the report" stuff got merged. I really dislike that it whines if I do Reported-by: followed by Link:.
1
0
0
@dickon Oh I totally didn't interpret as figurehead. I know we talked about the crypto support patches at FOSDEM w/ him, so I figured it was a "he sent it, but we all worked on it" type of comment.
Sounds like you guys are doing a pretty good job of internships.
> He's also the team's best git wrangler, which is actually worrying me; he goes back to uni in September...
Oof. git-wranger-in-chief is kinda my job title too, although I've managed to gradually improve everyone's ability over the last few years.
Sounds like you guys are doing a pretty good job of internships.
> He's also the team's best git wrangler, which is actually worrying me; he goes back to uni in September...
Oof. git-wranger-in-chief is kinda my job title too, although I've managed to gradually improve everyone's ability over the last few years.
1
0
1
@dickon I'm not really aware of the timing of those changes, but I assume they changed midway through your software support for the extensions. Did it also change late enough to affect hardware tapeout (although you probably cannot answer that) and/or after public review?
1
0
1
Conor Dooley
conor
RISC-V ISA string stuff makes my head hurt.
Claims that the spec definitions are stable just blows my mind. I'd swear that the biggest pain in the arse patches are those dealing with passing it that to a toolchain, particularly the removal of Zicsr/Zifencei from I crap.
Claims that the spec definitions are stable just blows my mind. I'd swear that the biggest pain in the arse patches are those dealing with passing it that to a toolchain, particularly the removal of Zicsr/Zifencei from I crap.
1
0
2
@pdp7 I have the following in mine:
# Patch syntax highlighting
color normal white default
color body brightwhite default ^[[:space:]].*
color body brightwhite default ^(diff).*
color body green default ^[\+].*
color body red default ^[\-].*
color body brightblue default [@@].*
color body brightwhite default ^(\s).*
Does the job fine ¯\_(ツ)_/¯
# Patch syntax highlighting
color normal white default
color body brightwhite default ^[[:space:]].*
color body brightwhite default ^(diff).*
color body green default ^[\+].*
color body red default ^[\-].*
color body brightblue default [@@].*
color body brightwhite default ^(\s).*
Does the job fine ¯\_(ツ)_/¯
1
0
0
@asb @palmer I'll make an account for this llvm thing later & copy-pasta into that if that helps.
Permissive would be great, as hopefully we can stick to one order in the future.
Looks like we'll probably have to do some Makefile dance around older gcc/clang versions but at least going forward it should be not too bad.
Permissive would be great, as hopefully we can stick to one order in the future.
Looks like we'll probably have to do some Makefile dance around older gcc/clang versions but at least going forward it should be not too bad.
1
0
0
@asb Assuming that I cannot reply by email, I would very much be in favour of keeping the things aligned.
From a kernel PoV, we don't yet have any X stuff to worry about w/ march at the moment as the only vendor specific stuff is handballed asm (see arch/riscv/include/asm/errata_list.h).
There's no S stuff that we pass to the compiler yet either as far as a quick check reports.
Alignment with gcc is helpful, permissiveness is better?
Given "canonical order" can, and has, change(d) in the past I think it's good to insulate against it happening again.
Conjuring up march is bad enough as things stand w/ availability with given toolchain versions (I kinda hit a brick wall with rust + gcc as I don't know how to test what version of libclang bindgen is backed by).
Having to do special handing of different versions of gcc/clang whenever we do actually need to add Sfoo or Xfoo sounds like another layer of misery I would love to avoid.
Ideally one order would work for all versions of gcc and clang, but it doesn't sound like it is?
- So gcc wanted Z before X, but it now does what? Allows any order? (The
comment about "this was fixed recently" confuses me a bit, sorry)
- clang used to want Z/X/S & now wants Z/S/X? Is it too late to avoid a released clang
that uses Z/S/X rather than your suggested permissive behaviour?
Also CC @palmer :)
From a kernel PoV, we don't yet have any X stuff to worry about w/ march at the moment as the only vendor specific stuff is handballed asm (see arch/riscv/include/asm/errata_list.h).
There's no S stuff that we pass to the compiler yet either as far as a quick check reports.
Alignment with gcc is helpful, permissiveness is better?
Given "canonical order" can, and has, change(d) in the past I think it's good to insulate against it happening again.
Conjuring up march is bad enough as things stand w/ availability with given toolchain versions (I kinda hit a brick wall with rust + gcc as I don't know how to test what version of libclang bindgen is backed by).
Having to do special handing of different versions of gcc/clang whenever we do actually need to add Sfoo or Xfoo sounds like another layer of misery I would love to avoid.
Ideally one order would work for all versions of gcc and clang, but it doesn't sound like it is?
- So gcc wanted Z before X, but it now does what? Allows any order? (The
comment about "this was fixed recently" confuses me a bit, sorry)
- clang used to want Z/X/S & now wants Z/S/X? Is it too late to avoid a released clang
that uses Z/S/X rather than your suggested permissive behaviour?
Also CC @palmer :)
2
0
1
@monsieuricon my aul lad thinks the folding thing is great. To each their own I guess!
0
0
0