On Sun, Jan 5, 2025 at 2:33 PM Miguel Ojeda
wrote:
>
> Thanks for the report! I think there is nothing to be done here given
> the details above.
To clarify: v6.11.y is newer (and EOL), v6.12.y LTS is newer, and
older LTSs had the Rust toolchain pinned.
If there is something I a
On Sun, Jan 5, 2025 at 9:42 AM Naresh Kamboju wrote:
>
> The following kselftest rust builds failed on sashal/linus-next.git
> due to following build warnings / errors.
>
> Good: 829d8581c398a96deea1d6bc78578950347dcbec
> Bad: b2d472701a703596889c3fd067fd8929aeffc4be
These seem unrelated, old b
On Fri, Dec 13, 2024 at 9:10 AM David Gow wrote:
>
> v5 here is a small set of fixes and a rebase of the previous versions.
> If there are no major issues, I'd like to land this soon so it can be
> used and tested ready for 6.14.
Thanks as usual David for keeping this one alive over time.
I was
On Fri, Dec 13, 2024 at 9:10 AM David Gow wrote:
>
> +/// In some cases, you need to call test-only code from outside the test
> case, for example, to
> +/// create a function mock. This function can be invoked to know whether we
> are currently running a
> +/// KUnit test or not.
The documenta
On Fri, Dec 13, 2024 at 9:10 AM David Gow wrote:
>
> +#[allow(unused_unsafe)]
Should this be in the first patch?
> -unsafe { core::ptr::addr_of_mut!(KUNIT_TEST_SUITE) };
> +unsafe {
> +core::ptr::addr_of_mut!(KUNIT_TEST_SUITE)
> +
On Fri, Dec 13, 2024 at 9:10 AM David Gow wrote:
>
> +/// The test case should have the signature
> +/// `unsafe extern "C" fn test_case(test: *mut crate::bindings::kunit)`.
I guess this is here so that people can copy-paste it (i.e. users)?
However, given it is private (i.e. users are not expect
On Mon, Dec 16, 2024 at 5:31 PM Danilo Krummrich wrote:
>
> Thanks! If nothing else comes up, I'll send you a v7 end of this week
> addressing
> the two minor things I just replied to (remove wrong return statement in
> iounmap() helper, `pci::DeviceId` naming and `Deref` impl).
If you are going
On Mon, Nov 25, 2024 at 2:29 PM Neal Gompa wrote:
>
> As my Acked-by was removed, I'm sorry to say that there is no point
> for me to provide feedback since it is unwanted.
>
> I hope it lands soon, but I also hope the people here who decided that
> a person's efforts aren't worth recording becaus
On Sat, Nov 9, 2024 at 9:18 AM David Gow wrote:
>
> Is there somewhere else we can put the attribute to support this
> without having to either disable the warning, or use the experimental
> feature globally?
Yeah, on the item, e.g. https://godbolt.org/z/oo8osadn4:
const _: () = {
st
On Sat, Nov 2, 2024 at 1:08 AM Boqun Feng wrote:
>
> Hmm.. so I think clippy won't warn for a normal Rust #[test] function:
>
> https://github.com/rust-lang/rust-clippy/pull/7811
That is a very good point. It is a bit surprising that those details
are not documented, but we could mimic th
On Fri, Nov 1, 2024 at 10:38 PM Boqun Feng wrote:
>
> but this lint doesn't make sense to me, I would say we just drop this
> lint?
I am not sure if it is intended to fire there (i.e. to resolve
constants), but seems OK since it is not something one would want
normally to write except in exceptio
On Fri, Nov 1, 2024 at 7:03 AM Boqun Feng wrote:
>
> This time, I try implementing a generic atomic type `Atomic`, since
> Benno and Gary suggested last time, and also Rust standard library is
> also going to that direction [1].
I would like to thank Boqun for trying out this approach, even when
Hi Naresh,
On Mon, Sep 16, 2024 at 9:17 PM Naresh Kamboju
wrote:
>
> The x86 rust gcc builds failed on the Linux next-20240917 due to following
> build
> warnings / errors with rustgcc for selftests rust builds.
>
> First seen on next-20240917
> Good: next-20240913
> BAD: next-20240917
>
>
On Fri, Aug 23, 2024 at 7:24 PM Sami Tolvanen wrote:
>
> I assume they wanted to avoid conflicts between Rust-specific
> environment variables and existing Kbuild variables. Note that
> KBUILD_MODFILE is also double quoted for the C preprocessor, which
> isn't needed for Rust. Miguel, do you remem
On Wed, Aug 21, 2024 at 7:08 PM Boqun Feng wrote:
>
> Have you try this with "make O="? I hit the following issue, but I
> am rebasing on rust-dev, so I might miss something:
>
> error: couldn't read ../rust/kernel/arch_static_branch_asm.rs: No
> such file or directory (os error 2)
>
On Mon, Jul 8, 2024 at 11:42 PM Luis Chamberlain wrote:
>
> The rationale here is that a rust binding means commitment then also
> from fresh blood to help co-maintain review C / Rust for exising code
> when there is will / desire to collaborate from an existing C maintainer.
>
> I realize this ma
On Fri, Jun 7, 2024 at 12:52 PM Peter Zijlstra wrote:
>
> I'm sorry, but 30+ years of reading ! as NOT (or factorial) isn't going
> to go away. So I'm reading your macros do NOT rule.
It makes it clear what is macro call or not. They could have gone for
UPPERCASE names (for instance), yes. On the
On Thu, Jun 6, 2024 at 7:19 PM Peter Zijlstra wrote:
>
> This is absolutely unreadable gibberish -- how am I supposed to keep
> this in sync with the rest of the static_call infrastructure?
Yeah, they are macros, which look different from "normal" Rust code.
Is there something we could do to hel
Hi Nick,
On Mon, Apr 19, 2021 at 10:36 PM Nick Desaulniers
wrote:
>
> This is a much different process than drafts thrown over the wall.
> What hope do any kernel contributors have to participate in the ISO
> WGs, other than hoping their contributions to a draft foresee/address
> any concerns mem
On Mon, Apr 19, 2021 at 10:18 PM Matthew Wilcox wrote:
>
> Yes, I agree, we need a better story for name mangling.
> My proposal is that we store a pretty name which matches the source
> (eg rust_binder::range_alloc) and a sha1 of the mangled symbol
> (40 bytes of uninteresting hex). Symbol resol
Hi David,
On Mon, Apr 19, 2021 at 10:01 PM David Sterba wrote:
>
> for simple functions it's barely parseable but the following is hardly
> readable
>
> translates to
>
>core[8787f43e282added]::fmt::Debug>::fmt
Some details can be omitted without much problem, e.g. try the `-i`
option of `c+
On Sat, Apr 17, 2021 at 6:24 AM Willy Tarreau wrote:
>
> My concern was to know what field to look at to reliably detect an error
> from the C side after a sequence doing C -> Rust -> C when the inner C
> code uses NULL to mark an error and the upper C code uses NULL as a valid
> value and needs t
On Sat, Apr 17, 2021 at 4:21 PM Willy Tarreau wrote:
>
> Well, I can't express how much I hate abstractions because I constantly
> need to know what it's doing under the hood, and I spend my time reading
> the output asm code because I always want to confirm my assumptions about
> the compiler not
On Sat, Apr 17, 2021 at 12:04 AM Willy Tarreau wrote:
>
> But my point remains that the point of extreme care is at the interface
> with the rest of the kernel because there is a change of semantics
> there.
>
> Sure but as I said most often (due to API or ABI inheritance), both
> are already excl
On Fri, Apr 16, 2021 at 10:58 PM Willy Tarreau wrote:
>
> No, two:
> - ok in %rax (seems like it's "!ok" technically speaking since it
> returns 1 on !ok and 0 on ok)
> - foo_or_err in %rdx
Yes, but that is the implementation -- conceptually you only have one
or the other, and Rust won't
On Fri, Apr 16, 2021 at 10:22 PM Willy Tarreau wrote:
>
> So it simply does the equivalent of:
>
> struct result {
> int status;
> int error;
> };
Not exactly, it is more like a tagged union, as Connor mentioned.
However, and this is the critical bit: it is a compile-time error to
On Sun, Apr 11, 2021 at 11:27 PM Michal Suchánek wrote:
>
> Yes, I do have the rust support.
I applied your patch in rust-next and it is in the latest linux-next,
let me know if that helped.
Masahiro, if you want to apply it on your side, just let me know!
Cheers,
Miguel
On Fri, Apr 16, 2021 at 8:10 PM Al Viro wrote:
>
> How well would ? operator fit that pattern? _If_ it's just a syntax sugar
> along the lines of "if argument matches Err(_), return Err(_)", the types
> shouldn't be an issue, but that might need some fun with releasing resources,
> etc. If it's
On Fri, Apr 16, 2021 at 7:05 PM Linus Torvalds
wrote:
>
> Typical Rust error handling should match the regular kernel
> IS_ERR/ERR_PTR/PTR_ERR model fairly well, although the syntax is
> fairly different (and it's not limited to pointers).
Yeah, exactly. We already have a `KernelResult` type whic
On Fri, Apr 16, 2021 at 3:38 PM Peter Zijlstra wrote:
>
> So if I read all this right, rust compiles to .o and, like any other .o
> file is then fed into objtool (for x86_64). Did you have any problems
> with objtool? Does it generate correct ORC unwind information?
I opened an issue a while ago
On Fri, Apr 16, 2021 at 6:14 PM Willy Tarreau wrote:
>
> I'm really afraid by languages which force developers to do this or that.
> Many bugs in C come from casts because developers know their use case
> better than the compiler's developers, and result in lack of warnings
> when the code evolves
On Fri, Apr 16, 2021 at 5:43 PM Peter Zijlstra wrote:
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2659.htm
>
> That's just not making any damn sense what so ever. That seems to be
> about sprinkling abort() all over the place, which is just total
> rubbish.
No, it is not about that. It i
On Fri, Apr 16, 2021 at 4:19 PM Peter Zijlstra wrote:
>
> Does this also not prohibit constructs where modification must be done
> while holding two locks, but reading can be done while holding either
> lock?
Yeah, this came up in some discussions we had. There are some locking
patterns that we n
On Fri, Apr 16, 2021 at 1:24 PM Peter Zijlstra wrote:
>
> IMO RAII is over-valued, but just in case you care, the below seems to
> work just fine. No fancy new language needed, works today. Similarly you
> can create refcount_t guards, or with a little more work full blown
> smart_ptr crud.
Pleas
Hi Stephen,
On Fri, Apr 16, 2021 at 9:58 AM Stephen Rothwell wrote:
>
> from the char-misc tree and commit:
>
> 1fed5dee5fbb ("Android: Binder IPC in Rust (WIP)")
>
> from the rust tree.
If you prefer, I can take out the binder bits from rust-next since
they will be submitted separately anyhow
On Thu, Apr 15, 2021 at 8:03 PM Nick Desaulniers
wrote:
>
> Until then, I don't see why we need to permit developers to express
> such flexibility for just the Rust code, or have it differ from the
> intent of the C code. Does it make sense to set RUST_OPT_LEVEL_3 and
> CC_OPTIMIZE_FOR_SIZE? I dou
On Thu, Apr 15, 2021 at 9:10 AM Greg Kroah-Hartman
wrote:
>
> Let's see what happens here, this patchset is a great start that
> provides the core "here's how to build rust in the kernel build system",
> which was a non-trivial engineering effort. Hats off to them that "all"
> I had to do was suc
On Thu, Apr 15, 2021 at 3:38 AM Kees Cook wrote:
>
> Before anything else: yay! I'm really glad to see this RFC officially
> hit LKML. :)
Thanks! :)
> When originally learning Rust I was disappointed to see that (by default)
> Rust similarly ignores the overflow problem, but I'm glad to see the
Hi Nathan,
Sorry, with all the other things I ended up not replying to you before
going to sleep.
On Wed, Apr 14, 2021 at 8:59 PM Nathan Chancellor wrote:
>
> Shuffling this around will cause this issue (I never saw you CC'd on the
> thread).
>
> https://lore.kernel.org/r/f6218ac526a04fa4d4406f9
On Thu, Apr 15, 2021 at 2:23 AM Nick Desaulniers
wrote:
>
> Looks like Wedson's writeup is now live. Nice job Wedson!
> https://security.googleblog.com/2021/04/rust-in-linux-kernel.html
+1 It is very nicely written and explains the semaphore samples
(included in the RFC) he wrote, with nice table
On Thu, Apr 15, 2021 at 1:47 AM Nick Desaulniers
wrote:
>
> I'm ok with this approach, but I'm curious:
> If the user made a copy of the CLANG_FLAGS variable and modified its
> copy, would TENTATIVE_CLANG_FLAGS even be necessary? IIUC,
> TENTATIVE_CLANG_FLAGS is used to filter out certain flags be
On Thu, Apr 15, 2021 at 1:19 AM Nick Desaulniers
wrote:
>
> Rather than check the origin (yikes, are we intentionally avoiding env
> vars?), can this simply be
> ifneq ($(CLIPPY),)
> KBUILD_CLIPPY := $(CLIPPY)
> endif
>
> Then you can specify whatever value you want, support command line or
> en
Hi Nick,
Thanks a lot for looking into this!
On Thu, Apr 15, 2021 at 12:18 AM Nick Desaulniers
wrote:
>
> Was this TODO meant to be removed, or is it still pending? If pending,
> on what? Being able to link back on itself if/once merged?
Still pending -- the plan is to upload the docs to kernel
On Wed, Apr 14, 2021 at 11:55 PM Nick Desaulniers
wrote:
>
> Assuming this will at least be part of Wedson's core responsibilities,
> shouldn't this be "Supported." Per Maintainers:
Yeah, we were waiting until a couple other announcements to change it
-- but it will most likely be "Supported" by
On Wed, Apr 14, 2021 at 10:10 PM Matthew Wilcox wrote:
>
> On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> > - Manish Goregaokar implemented the fallible `Box`, `Arc`, and `Rc`
> > allocator APIs in Rust's `alloc` standard library for us.
>
> There's a philosophical point
On Wed, Apr 14, 2021 at 9:45 PM Linus Torvalds
wrote:
>
> With the main point of Rust being safety, there is no way I will ever
> accept "panic dynamically" (whether due to out-of-memory or due to
> anything else - I also reacted to the "floating point use causes
> dynamic panics") as a feature in
On Wed, Apr 14, 2021 at 9:45 PM Matthew Wilcox wrote:
>
> How about doing something a bit more utf-8-like?
>
> len = data[0];
> if (len == 0)
> error
> else if (len < 128)
> return len;
> else if (len < 192)
> return 1
On Wed, Apr 14, 2021 at 9:31 PM Linus Torvalds
wrote:
>
> Again, excuse my lack of internal Rust knowledge, but when do these
> end up being an issue?
>
> If the Rust compiler ends up doing hidden allocations, and they then
> cause panics, then one of the main *points* of Rustification is
> entire
On Wed, Apr 14, 2021 at 9:34 PM Linus Torvalds
wrote:
>
> Honestly, I'd like to see a real example. This is fine for testing,
> but I'd like to see something a bit more real, and a bit less special
> than the Android "binder" WIP that comes a few patches later.
>
> Would there be some kind of real
On Wed, Apr 14, 2021 at 9:19 PM Linus Torvalds
wrote:
>
> Not being a Rust person, I can only guess based on random pattern
> matching, but this _looks_ like these "panicking intrinsics" panic at
> run-time (by calling BUG()).
Your pattern matching works well :)
> Is there some way these things
er to upstream, which is the
best case scenario :)
Reviewed-by: Miguel Ojeda
[1]
https://github.com/facebook/zstd/commit/f2d6db45cd28457fa08467416e8535985f062859
Cheers,
Miguel
On Tue, Mar 30, 2021 at 1:07 PM Jani Nikula wrote:
>
> FWIW, and this should be obvious, I think going with what's natural for
> documenting Rust source code is the right choice. Markdown as parsed by
> rustdoc. People will expect Rust documentation comments to just work,
> without some kernel spe
On Thu, Mar 25, 2021 at 11:18 PM Matthew Wilcox wrote:
>
> The rust code is alredy coming though ...
>
> rust/kernel/buffer.rs:/// A pre-allocated buffer that implements
> [`core::fmt::Write`].
>
> so now we have three formats. Markdown and RST are _very_ similar, but
> not identical [1]. Oh, a
On Mon, Mar 29, 2021 at 9:34 PM Jonathan Corbet wrote:
>
> If we're going to talk about incorporating Rust into the doc system, we
> should probably include some Rust folks - thus, I'm adding Miguel.
Thanks a lot Jonathan for the Cc!
I will read and answer the other emails.
Cheers,
Miguel
x27;t there, at least in the current version in GitHub.
Acked-by: Miguel Ojeda
Cheers,
Miguel
Hi Linus,
Please pull this fix for auxdisplay.
Thanks!
Cheers,
Miguel
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0:
Linux 5.12-rc3 (2021-03-14 14:41:02 -0700)
are available in the Git repository at:
https://github.com/ojeda/linux.git tags/auxdisplay-for-lin
On Thu, Mar 25, 2021 at 8:02 AM Masahiro Yamada wrote:
>
> This is sensible for tools that interface to users.
> Users have no interest in which language is used
> internally.
Agreed in the general case (e.g. everyday tools). In the kernel's
case, however, I think it is not as important.
And I g
editor-independent manner,
> I think editorconfig (patch [1]) is a saner solution.
>
> [1] https://lore.kernel.org/lkml/20200703073143.423557-1-da...@kdrag0n.dev/
>
> Signed-off-by: Masahiro Yamada
+1 It is great to get rid of those.
For auxdisplay:
Reviewed-by: Miguel Ojed
On Tue, Mar 23, 2021 at 1:16 PM Michael Ellerman wrote:
>
> It would be nice to be in the CI. I was building natively so I haven't
> tried cross compiling yet (which we'll need for CI).
Indeed -- in the CI we already cross-compile arm64 (and run under QEMU
both arm64 as well as x86_64), so it is
Hi Michael,
On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman wrote:
>
> Hi all,
>
> Here's a first attempt at getting the kernel Rust support building on powerpc.
Thanks a *lot*! It is great to have more architectures rolling.
> It's powerpc64le only for now, as that's what I can easily test gi
On Tue, Mar 23, 2021 at 4:27 AM Michael Ellerman wrote:
>
> ppc64le only for now. We'll eventually need to come up with some way to
> change the target.json that's used based on more than just $(ARCH).
Indeed, it is one reason I didn't tackle e.g. x86 32-bit, because I
wanted to figure out how to
On Mon, Mar 22, 2021 at 1:20 PM Miguel Ojeda
wrote:
>
> I'll take a look at fixing those soon.
For those that may read this or run into the same issue: this started
with the LLVM 12 upgrade in rustc nightlies. Therefore, please avoid
the very latest nightlies (>= nightly-2021-03-05
On Mon, Mar 22, 2021 at 3:48 PM Geert Uytterhoeven wrote:
>
> You can find an image of the full character set at
> https://drive.google.com/file/d/1h3EYFBWHIjh8B_cwPA5ocAD-lFYipRie/view
Should we put it in e.g. the Docs or just alongside this file?
Cheers,
Miguel
On Mon, Mar 22, 2021 at 3:48 PM Geert Uytterhoeven wrote:
>
> Thanks for your comments!
We could use this as a showcase on how to structure and present a
patch series! ;-)
Cheers,
Miguel
On Mon, Mar 22, 2021 at 3:48 PM Geert Uytterhoeven wrote:
>
> + struct device *dev = &pdev->dev;
Do we want helpers like this to be `*const` (assuming they can)? (same
for patch 12).
Cheers,
Miguel
Hi Joshua,
On Mon, Mar 22, 2021 at 3:53 AM Joshua Abraham wrote:
>
> Cheers, using rustc 1.52.0-nightly (9b471a3f5 2021-02-19) fixed the
> issue. Interesting that the newer nightly compiler creates these new
> relocations for the code!
Thanks a lot for the report and for confirming that worked f
Hi Alexander,
On Sun, Mar 21, 2021 at 8:14 PM Alexander Lochmann
wrote:
>
> diff --git a/Documentation/dev-tools/kcov.rst
> b/Documentation/dev-tools/kcov.rst
> index d2c4c27e1702..e105ffe6b6e3 100644
> --- a/Documentation/dev-tools/kcov.rst
> +++ b/Documentation/dev-tools/kcov.rst
> @@ -127,6 +
On Sun, Mar 21, 2021 at 9:03 PM Miguel Ojeda
wrote:
>
> The supported architectures are in
> Documentation/rust/arch-support.rst, so we should link to that.
>
> Yeah, this is mentioned on the bindgen section in quick-start.rst, I
> will try to improve make it more clear, perh
Hi Joshua,
On Mon, Mar 22, 2021 at 1:13 AM Joshua Abraham wrote:
>
> $ rustc --version
> rustc 1.52.0-nightly (61edfd591 2021-03-20)
Please give a go to the nightly from a month ago, i.e. 2021-02-20.
Cheers,
Miguel
On Sun, Mar 21, 2021 at 10:58 PM Miguel Ojeda
wrote:
>
> I tried your config and it worked, so it looks like the problem is
> your old libclang (7) does not recognize some of the flags. If you can
> try a newer LLVM installation, it would be great to confirm it.
Yeah, LLVM introduced
On Sun, Mar 21, 2021 at 9:56 PM Pavel Machek wrote:
>
> Done, in a private message.
I tried your config and it worked, so it looks like the problem is
your old libclang (7) does not recognize some of the flags. If you can
try a newer LLVM installation, it would be great to confirm it.
Neverthele
On Sun, Mar 21, 2021 at 9:56 PM Pavel Machek wrote:
>
> Thanks for your work :-).
You're welcome! We're trying our best :-)
> Actually x86-32 would be useful for me. That's my test machine.
Sorry... :-( x86 32-bits, ppc64el, s390x... are some of the ones we
will look into soon, but possibly aft
Hi Pavel,
On Sun, Mar 21, 2021 at 8:37 PM Pavel Machek wrote:
>
> First try was on x86-32. It took me a whlie to figure out the problem,
> hence the diff below.
Thanks a lot for trying it out and for the feedback! :-)
The supported architectures are in
Documentation/rust/arch-support.rst, so we
On Sun, Mar 21, 2021 at 1:30 PM Michael Ellerman wrote:
>
> Yes. But Monday in UTC+11 :)
Yeah :-) I'm on it.
Cheers,
Miguel
On Sat, Mar 20, 2021 at 6:33 AM Stephen Rothwell wrote:
>
> Daniel Axtens reported the same breakage on powerpc. I bisected it to
> the same commit. More experimentation shows that if you reverse just
> the change to include/linux/moduleparam.h the above warnings go away.
> So
>
> -#define MAX_P
On Sat, Mar 20, 2021 at 7:07 AM Miguel Ojeda
wrote:
>
> Sorry for that, and thanks a lot for taking a look. For the Rust
> support I had to increase a few limits, mainly the symbol length. Let
> me check and I'll report back.
Reproduced on s390. However, under defconfig, one als
On Sat, Mar 20, 2021 at 7:49 AM Miguel Ojeda
wrote:
>
> Reproduced on s390. However, under defconfig, one also needs to revert
> kernel/livepatch/core.c to avoid triggering the assert, i.e.:
Stephen: I will put this in rust-next so that others don't see
problems on their side and
On Fri, Mar 19, 2021 at 7:45 PM Ansuel Smith wrote:
>
> Sorry, didn't notice that. Considering that checkpatch complains and
> some reviewers actually state that 100 is the new limit, I think it's
> time to update the file.
IIUC, 80 is still the soft limit, but 100 is now the hard limit.
Cc'ing
On Thu, Mar 18, 2021 at 7:24 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the rust tree, today's linux-next build (htmldocs) produced
> this warning:
>
> Documentation/rust/coding.rst:24: WARNING: Unexpected indentation.
Ah, so docs are built in -next too? That is very nice. I'll fix
On Thu, Mar 18, 2021 at 7:03 AM Valdis Klētnieks
wrote:
>
> Or declare that gcc6 is the minimum for building the kernel.
Cc'ing some interested people in raising GCC's version for one reason
or another, so that we put this as another one in the pile of reasons
:-)
https://lore.kernel.org/lkml/CA
On Thu, Mar 18, 2021 at 5:37 AM Stephen Rothwell wrote:
>
> I fixed it up (see below - I think I got this right ...) and can carry
> the fix as necessary. This is now fixed as far as linux-next is
> concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when you
On Thu, Mar 11, 2021 at 11:34 AM Masahiro Yamada wrote:
>
> Hmm, that is a simple, clean idea.
> Then, we can simply read out the file
>
> $ cat scripts/min_versions/gcc
> 4.9.0
Exactly!
> I do not know how to handle
> per-arch versions in this case.
Perhaps we should just push for 5.1.0 everyw
.23.0
+1 to creating a central place for all minimum versions.
Acked-by: Miguel Ojeda
I wonder if you considered creating a folder with files like
`scripts/min_versions/gcc` containing the version string. That would
make it easier for reading from other languages or even importing them
On Wed, Mar 10, 2021 at 6:51 PM Sebastian Andrzej Siewior
wrote:
>
> I assumed you are going to apply it but I don't see it in -next as of
> today. Is there anything I need to do?
Ah, since you said you were posting a patch, I kept this in the
waiting list. I will apply the latest one then.
Chee
n.
>
> Fixes: aec6c60a01d3 ("kbuild: check the minimum compiler version in Kconfig")
> Signed-off-by: Masahiro Yamada
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Fri, Mar 5, 2021 at 10:25 PM Linus Torvalds
wrote:
>
> And regardless of even _those_ issues, you still should do all the
> other syntactic tokenization stuff (ie all the quoting, the the
> character handling: 'a' is a valid C token, but if you see the string
> "it's" outside of a comment, that
On Thu, Mar 4, 2021 at 1:09 AM Konstantin Komarov
wrote:
>
> - use clang-format 11.0 instead of 10.0 to format code
Out of curiosity: was this due to some specific reason? i.e. have you
found it provides better output? (it is useful to know this to justify
later an increase of the minimum version
the comment about sparse not being yet able to constant
> fold __builtin_bswap*() and remove the corresponding test of __CHECKER__.
>
> Signed-off-by: Luc Van Oostenryck
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Thu, Feb 25, 2021 at 9:18 PM Nathan Chancellor wrote:
>
> Indeed. Any wins that we can get with compile time, we should take.
> Clang is being widely used in production systems now so I feel like with
> a trivial change plus user visible impact, it should be backported.
>
> Not to mention that
On Thu, Feb 25, 2021 at 9:14 PM Kees Cook wrote:
>
> It's a trivial change, so I think it's worth it?
It is simple, but it is not trivial since it may change codegen.
Acked-by: Miguel Ojeda
Cheers,
Miguel
On Tue, Feb 16, 2021 at 11:22 AM Preeti Nagar wrote:
>
> The changes introduce a new security feature, RunTime Integrity Check
> (RTIC), designed to protect Linux Kernel at runtime. The motivation
> behind these changes is:
> 1. The system protection offered by Security Enhancements(SE) for
> Andr
On Tue, Feb 16, 2021 at 7:26 PM Sebastian Andrzej Siewior
wrote:
>
> That should be part of the commit message. You can always rewind to the
> commit message that introduce something and check if the commit message
> made sense or ignored a detail which made it wrong (or so).
No, it shouldn't. Co
On Tue, Feb 16, 2021 at 11:28 AM Sebastian Andrzej Siewior
wrote:
>
> Could we please avoid documenting the obvious? It is more or less common
> knowledge that the write callback (like any other) is preemptible user
> context (in which write occurs). The same is true for register/probe
> functions
Hi Sebastian,
On Sat, Feb 13, 2021 at 5:50 PM Sebastian Andrzej Siewior
wrote:
>
> charlcd_write() is invoked as a VFS->write() callback and as such it is
> always invoked from preemptible context and may sleep.
Can we put this sentence as a comment in the code, right before the
call to cond_res
Hi Linus,
A few bits for auxdisplay. Please pull.
Cheers,
Miguel
The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04:
Linux 5.11-rc5 (2021-01-24 16:47:14 -0800)
are available in the Git repository at:
https://github.com/ojeda/linux.git tags/auxdisplay-for-linus-v5.
Hi Sebastian,
On Tue, Feb 9, 2021 at 10:01 AM Sebastian Andrzej Siewior
wrote:
>
> If I post series with more than just one patch I have a cover letter
> including:
Yeah, it is a bit confusing when reading without the context (it is
hard to keep up with everything going on unless you work full-t
On Mon, Feb 8, 2021 at 9:41 PM Sebastian Andrzej Siewior
wrote:
>
> It hurts to keep in_interrupt() because it is desired to have it removed
> from drivers. The problem is that pattern is often copied and people
> sometimes get it wrong. For instance, the code here invoked schedule()
> based on in
On Mon, Feb 8, 2021 at 8:07 PM Sebastian Andrzej Siewior
wrote:
>
> Yes.
In what way?
> No. If you know the context, pass it along like this is done for
> kmalloc() for instance.
What do you mean?
> The long term plan is not make it available to
> divers (i.e. core code only where the context
gt;
> Remove `in_interrupt()' and use `cond_resched()' to schedule every 32
> iteration if needed.
>
> Cc: Miguel Ojeda Sandonis
> Signed-off-by: Sebastian Andrzej Siewior
Cc'ing Geert and Willy too.
Thanks for the patch!
Cheers,
Miguel
Signed-off-by: Miguel Ojeda
---
.mailmap| 1 +
CREDITS | 9 +++--
Documentation/admin-guide/auxdisplay/cfag12864b.rst | 2 +-
Documentation/admin-guide/auxdisplay/ks0108.rst | 2 +-
MAINTAINERS
1 - 100 of 743 matches
Mail list logo
